HTML常用特殊字符 ：只要你认识了 HTML 标记，你便会知道特殊字符的用处。

常用标点

箭头类

基本形状类

货币类

字母符号

数学类

音乐符号类

对错号

全都是星星

星座类

国际象棋类

扑克牌类

希腊字母

十字

法律符号

标点和符号

希腊文和科普特文

Multi Tenancy usually plays an important role in the business case for SAAS solutions. Spring Boot and Hibernate provide out-of-the-box support for different Multi-tenancy strategies. Configuration however becomes more complicated, and the available code examples are limited. In the first part of this blog series, we’ll start by exploring the Multi Tenancy concept and three different architectural patterns for multi tenant data isolation. In the forthcoming episodes, we’ll deep dive into the details of implementing the different patterns usign Spring Boot, Spring Data and Liquibase.

BLOG SERIES PARTS

• Part 1: What is Multi Tenancy (this part)
• Part 2: Outlining an Implementation Strategy for Multi Tenant Data Access
• Part 3: Implementing the Database per Tenant pattern
• Part 4: Implementing the Schema per Tenant pattern
• Part 5: Implementing the Shared database with Discriminator Column pattern using Hibernate Filters
• Part 6: Implementing the Shared database with Discriminator Column pattern using Postgres Row Level Security
• Part 7: Combining the Shared Database pattern with Database per Group of Tenants (a.k.a. Shard) for additional scalability
• Part 8: Shared Database pattern with Hibernate 6

WHAT IS MULTI TENANCY?

By allowing one single, highly scalable software solution to serve many different customers, a scalable, elastic, agile and cost effective solution can be built. A software architecture in which a (logically) single instance of the software serves multiple tenants is frequently called a _multi-tenancy_ architecture. A _tenant_ is a group of users who share a common access with specific privileges to the software instance. Everything should be shared, except for the different customers’ data, which should be properly separated. Despite the fact that they share resources, tenants aren’t aware of each other, and their data is kept totally separate.

CONFLICTING REQUIREMENTS

As usual with architectural patterns, a multi-tenant architecture has to balance two partly conflicting needs or forces: On one hand, we would like to share as much as possible, in order to achieve:

• Better use of resources: One machine reserved for one tenant isn’t efficient, as that one tenant is not likely to use all of the machine’s computing power. By sharing machines among multiple tenants, use of available resources is maximized.
• Lower costs: With multiple customers sharing resources, a vendor can offer their services to many customers at a much lower cost than if each customer required their own dedicated infrastructure.
• Elasticity and Agility: With a shared infrastructure, onboarding new tenants can be much easier, quicker and cost efficient.

On the other hand, we would like to have a fool-proof separation of between tenants, in order to guarantee the privacy, confidentiality and consistency of each tenant’s data. We also have to avoid the problem with “noisy neighbors”, where a tenant that misbehaves potentially can disturb its neighboring tenants.

MULTI TENANCY PATTERNS

As we can see, a challenge lies in separating the data for each tenant, while still sharing as much as possible of the other resources. Three principal architectural patterns for Multi Tenancy can be identified, which differs in the degree of (physical) separation of the tenant’s data.

• Database per tenant

The most obvious way to separate the data owned by different tenants is to use a separate database per tenant. Using this pattern, the data is physically isolated per tenant, and hence the privacy and confidentiality of the data can easily be guaranteed (including administrative housekeeping such as backups and cleansing). The tradeoff is equally obvious, since the database infrastructure as well as database connection pools cannot be shared between tenants.

• Schema per tenant

A slight variation to is to use a separate _database schema_ per tenant, while sharing the database instance. The data for each tenant is logically isolated by the semantics of separate schemas as provided by the database engine. If the schemas is owned by a separate database user per tenant, the database engine’s security mechanism further guarantee the privacy and confidentiality of the data (note however that in such a case, the database connection pool cannot be reused by the data access layer).

• Shared database, using a Discriminator Column

The final pattern uses a fully shared database, in which data for all tenants are stored in the same table(s). An additional _discriminator_ column is added to each table, which needs to be included in an additional where clause in each and every query. This pattern provides the least data separation (leaving it to the application to guarantee privacy and confidentiality for the tenant’s data) but the maximum sharing of resources. From an infrastructure perspective, it is the conceptually simplest solution, whereas the complexity is pushed into the application. Since data is not separated at the database level, administrative housekeeping such as backups per tenant becomes more difficult.

CHOOSING A MULTI TENANCY PATTERN

Hence there are different pro’s and con’s with the three patterns above. The choice between them will be governed by the requirements of a particular solution. Database-per-tenant provides very strong data isolation between tenants, but requires more infrastructural resources and administrative work in setting up new tenants and performing database migrations. Hence there is an upper limit on the scalability of the Database-per-tenant pattern, both in size and the time required to onboard new tenants. Shared-database-with-Discriminator-column provides maximal sharing of infrastructural resources and hence excellent scalability, but with data isolation between tenants only guaranteed by the application layer.

If you have a smaller number of tenants (< 1000) and require strong guarantees for tenant data isolation, Database-per-tenant and Schema-per-tenant are the most frequent choices. Among them, Schema-per-tenant is usually a good balance between data separation and resource sharing. If you have a large number of tenants, Shared-database-with-Discriminator-column might be the only viable solution.

Sometimes, the most pragmatic approach is a mixed model, supporting different customer segments using different models.

SUMMARY

In this blog post, we have explored the Multi Tenancy concept and discussed three different architectural patterns for multi tenant data isolation. In the next part, we’ll dive into an implementation strategy for for Multi Tenant Data Access using Spring Boot, Spring Data, Hibernate and Liquibase, that allows us to implement the different multi tenant patterns transparently and efficiently.

npm包版本号详解

npm包在发布时，需要按照包版本语义化中的约定去更新设置，例如我们常见的1.0.0，1.0.1，0.0.1等这样的版本号，那么这些数字分别代表什么意思呢？下面我们将详细介绍。

npm版本号的组成

一个完整的版本号，由三部分组成：主版本号（major）、次版本号(minor)、修订版本号(patch)，简称X.Y.Z，具体含义：

• 主版本号（major）：项目（包）做了大量的变更，与旧的版本存在一定的不兼容性等问题。
• 次版本号（minor）：做了少量的变更或向下做了兼容。
• 修订版本号（patch）：修复上一个版本的bug或向下做兼容。

版本号变更的一般规则：

• 版本号只升不降，不得在数字前面加0。例如不能是1.01.0，应该是1.0.0。
• 当主版本号升级时，次版本号和修订版本号需要归零。例如1.1.1->2.0.0。
• 当次版本号升级时，主版本号不变，修订版本号归零。例如1.1.1->1.2.0。
• 当修订版本号升级时，主版本和次版本号都不变。例如1.1.1->1.1.2。
• 一般第一个正式版本应为1.0.0。
• 处于开发测试阶段的版本一般为0.y.z，如果不发布，则默认为0.0.0，如果发布第一个测试版本则是0.1.0，如果修复第一个测试版本则是0.1.1，如果更新第二个测试版本则是0.2.0。

版本标识符（标签）

格式：Major.Minor.Patch-Identifier.1，其中Identifier就是代表标识符，和版本号之间使用-隔离，后面则是当前标识符的版本版本号，每升级一次则+1

希望安装带标签的版本，必须明确指定标签或者版本号，否则安装的是最新的不带标签的版本。

版本运算符

版本运算符一般是指定一定范围的版本号，主要有~、-、^、<、>等。

~ 版本号只指定主版本号或者次版本号，例如：

^ 版本号

匹配第一个非0版本号

npm 安装包时，默认使用 ^ 匹配版本。

~ 与 ^ 对比

创建用户

CREATE USER 'usernamexxx'@'hostxxx' IDENTIFIED BY 'passwordxxx';

说明：

• hostxxx：指定该用户在哪个主机上可以登陆，如果是本地用户可用localhost，如果想让该用户可以从任意远程主机登陆，可以使用通配符%
• passwordxxx：该用户的登陆密码，密码可以为空，如果为空则该用户可以不需要密码登陆服务器

示例：

CREATE USER 'jack'@'localhost' IDENTIFIED BY '123456';
CREATE USER 'rose'@'192.168.38.110_' IDENDIFIED BY '123456';
CREATE USER 'rose'@'%' IDENTIFIED BY '123456';
CREATE USER 'rose'@'%' IDENTIFIED BY '';
CREATE USER 'rose'@'%';

注意：

创建用户后，该用户只能连接到数据库服务器，但并没有操作该数据库服务器的权限。

授权

说明：

• privilegesxxx：用户的操作权限，如SELECT，INSERT，UPDATE等，如果要授予所的权限则使用ALL
• databasenamexxx：数据库名
• tablenamexxx：表名，如果要授予该用户对所有数据库和表的相应操作权限则可用*表示，如*.*

示例：

GRANT SELECT, INSERT ON DbXXX.user TO 'jack'@'%';
GRANT ALL ON *.* TO 'jack'@'%';
GRANT ALL ON DbXXX.* TO 'jack'@'%';

注意：

1.  授权之后需要用户重连MySQL，才能获取相应的权限。
2. 用以上命令授权的用户不能给其它用户授权，如果想让该用户可以授权，用以下命令:

GRANT privilegesxxx ON databasenamexxx.tablenamexxx TO 'usernamexxx'@'hostxxx' WITH GRANT OPTION;

设置与更改用户密码

SET PASSWORD FOR 'usernamexxx'@'hostxxx' = PASSWORD('newpasswordxxx');

如果是当前登陆用户用:

SET PASSWORD = PASSWORD("newpasswordxxx");

示例：

SET PASSWORD FOR 'jack'@'%' = PASSWORD("123456");

撤销用户权限

REVOKE privilegexxx ON databasenamexxx.tablenamexxx FROM 'usernamexxx'@'hostxxx';

示例：

REVOKE SELECT ON *.* FROM 'jack'@'%';

注意：

假如你在给用户'jack'@'%'授权的时候是这样的（或类似的）：GRANT SELECT ON test.user TO 'jack'@'%'，则在使用REVOKE SELECT ON *.* FROM 'jack'@'%';命令并不能撤销该用户对test数据库中user表的SELECT 操作。相反，如果授权使用的是GRANT SELECT ON *.* TO 'jack'@'%';则REVOKE SELECT ON test.user FROM 'jack'@'%';命令也不能撤销该用户对test数据库中user表的Select权限。

具体信息可以用命令SHOW GRANTS FOR 'jack'@'%'; 查看。

删除用户

DROP USER 'usernamexxx'@'hostxxx';

mvn dependency:sources
mvn dependency:resolve -Dclassifier=javadoc

第一个命令尝试下载 pom.xml 中依赖的文件的源代码
第二个命令是尝试下载对应的 javadoc