diff --git a/notes/Git.md b/notes/Git.md index 2041b8f5..1695faad 100644 --- a/notes/Git.md +++ b/notes/Git.md @@ -79,7 +79,7 @@ Git 把每次提交都连成一条时间线。分支使用指针来实现，例 # 冲突 -当两个分支都对同一个文件进行了修改，在分支合并时就会产生冲突。 +当两个分支都对同一个文件的同一行进行了修改，在分支合并时就会产生冲突。

diff --git a/notes/分布式问题分析.md b/notes/分布式问题分析.md index 15e9f80e..81d7f9e0 100644 --- a/notes/分布式问题分析.md +++ b/notes/分布式问题分析.md @@ -11,11 +11,10 @@ * [使用场景](#使用场景) * [实现方式](#实现方式) * [五、分布式 Session](#五分布式-session) - * [1. 粘性 Session](#1-粘性-session) - * [2. 服务器 Session 复制](#2-服务器-session-复制) - * [3. Session 共享机制](#3-session-共享机制) - * [4. Session 持久化到数据库](#4-session-持久化到数据库) - * [5. Terracotta 实现 Session 复制](#5-terracotta-实现-session-复制) + * [1. Sticky Sessions](#1-sticky-sessions) + * [2. Session Replication](#2-session-replication) + * [3. Persistent DataStore](#3-persistent-datastore) + * [4. In-Memory DataStore](#4-in-memory-datastore) * [六、分库与分表带来的分布式困境与应对之策](#六分库与分表带来的分布式困境与应对之策) * [事务问题](#事务问题) * [查询问题](#查询问题) @@ -249,99 +248,37 @@ Zookeeper 提供了一种树形结构级的命名空间，/app1/p_1 节点表示 # 五、分布式 Session -如果不做任何处理的话，用户将出现频繁登录的现象，比如集群中存在 A、B 两台服务器，用户在第一次访问网站时，Nginx 通过其负载均衡机制将用户请求转发到 A 服务器，这时 A 服务器就会给用户创建一个 Session。当用户第二次发送请求时，Nginx 将其负载均衡到 B 服务器，而这时候 B 服务器并不存在 Session，所以就会将用户踢到登录页面。这将大大降低用户体验度，导致用户的流失，这种情况是项目绝不应该出现的。 +在分布式场景下，一个用户的 Session 如果只存储在一个服务器上，那么当负载均衡器把用户的下一个请求转发到另一个服务器上，该服务器没有保存用户的 Session，就可能导致用户需要重新进行登录等操作。 -## 1. 粘性 Session +

-### 原理 +## 1. Sticky Sessions -粘性 Session 是指将用户锁定到某一个服务器上，比如上面说的例子，用户第一次请求时，负载均衡器将用户的请求转发到了 A 服务器上，如果负载均衡器设置了粘性 Session 的话，那么用户以后的每次请求都会转发到 A 服务器上，相当于把用户和 A 服务器粘到了一块，这就是粘性 Session 机制。 +需要配置负载均衡器，使得一个用户的所有请求都路由到一个服务器节点上，这样就可以把用户的 Session 存放在该服务器节点中。 -### 优点 +缺点：当服务器节点宕机时，将丢失该服务器节点上的所有 Session。 -简单，不需要对 Session 做任何处理。 +

-### 缺点 +## 2. Session Replication -缺乏容错性，如果当前访问的服务器发生故障，用户被转移到第二个服务器上时，他的 Session 信息都将失效。 +在服务器节点之间进行 Session 同步操作，这样的话用户可以访问任何一个服务器节点。 -### 适用场景 +缺点：需要更好的服务器硬件条件；需要对服务器进行配置。 -- 发生故障对客户产生的影响较小； -- 服务器发生故障是低概率事件。 +

-## 2. 服务器 Session 复制 +## 3. Persistent DataStore -### 原理 +将 Session 信息持久化到一个数据库中。 -任何一个服务器上的 Session 发生改变，该节点会把这个 Session 的所有内容序列化，然后广播给所有其它节点，不管其他服务器需不需要 Session，以此来保证 Session 同步。 +缺点：有可能需要去实现存取 Session 的代码。 -### 优点 +

-可容错，各个服务器间 Session 能够实时响应。 +## 4. In-Memory DataStore -### 缺点 - -会对网络负荷造成一定压力，如果 Session 量大的话可能会造成网络堵塞，拖慢服务器性能。 - -### 实现方式 - -1. 设置 Tomcat 的 server.xml 开启 tomcat 集群功能。 -2. 在应用里增加信息：通知应用当前处于集群环境中，支持分布式，即在 web.xml 中添加<distributable/> 选项。 - -## 3. Session 共享机制 - -使用分布式缓存方案比如 Memcached、Redis，但是要求 Memcached 或 Redis 必须是集群。 - -使用 Session 共享也分两种机制，两种情况如下： - -### 3.1 粘性 Session 共享机制 - -和粘性 Session 一样，一个用户的 Session 会绑定到一个 Tomcat 上。Memcached 只是起到备份作用。 - -

- -### 3.2 非粘性 Session 共享机制 - -#### 原理 - -Tomcat 本身不存储 Session，而是存入 Memcached 中。Memcached 集群构建主从复制架构。 - -

- -#### 优点 - -可容错，Session 实时响应。 - -#### 实现方式 - -用开源的 msm 插件解决 Tomcat 之间的 Session 共享：Memcached_Session_Manager（MSM） - -## 4. Session 持久化到数据库 - -### 原理 - -拿出一个数据库，专门用来存储 Session 信息。保证 Session 的持久化。 - -### 优点 - -服务器出现问题，Session 不会丢失 - -### 缺点 - -如果网站的访问量很大，把 Session 存储到数据库中，会对数据库造成很大压力，还需要增加额外的开销维护数据库。 - -## 5. Terracotta 实现 Session 复制 - -### 原理 - -Terracotta 的基本原理是对于集群间共享的数据，当在一个节点发生变化的时候，Terracotta 只把变化的部分发送给 Terracotta 服务器，然后由服务器把它转发给真正需要这个数据的节点。它是服务器 Session 复制的优化。 - -

- -### 优点 - -这样对网络的压力就非常小，各个节点也不必浪费 CPU 时间和内存进行大量的序列化操作。把这种集群间数据共享的机制应用在 Session 同步上，既避免了对数据库的依赖，又能达到负载均衡和灾难恢复的效果。 +可以使用 Redis 和 Memcached 这种内存型数据库对 Session 进行存储，可以大大提高 Session 的读写效率。内存型数据库同样可以持久化数据到磁盘中来保证数据的安全性。 # 六、分库与分表带来的分布式困境与应对之策 @@ -366,6 +303,8 @@ Terracotta 的基本原理是对于集群间共享的数据，当在一个节点 - [Comparing Load Balancing Algorithms](http://www.jscape.com/blog/load-balancing-algorithms) - [负载均衡算法及手段](https://segmentfault.com/a/1190000004492447) - [Redirection and Load Balancing](http://slideplayer.com/slide/6599069/#) +- [Session Management using Spring Session with JDBC DataStore](https://sivalabs.in/2018/02/session-management-using-spring-session-jdbc-datastore/) +- [Apache Wicket User Guide - Reference Documentation](# Apache Wicket User Guide - Reference Documentation) - [集群/分布式环境下 5 种 Session 处理策略](http://blog.csdn.net/u010028869/article/details/50773174?ref=myread) - [浅谈分布式锁](http://www.linkedkeeper.com/detail/blog.action?bid=1023) - [深入理解分布式事务](https://juejin.im/entry/577c6f220a2b5800573492be) diff --git a/notes/数据库系统原理.md b/notes/数据库系统原理.md index cd13daa5..867c849f 100644 --- a/notes/数据库系统原理.md +++ b/notes/数据库系统原理.md @@ -258,9 +258,7 @@ lock-x(A)...unlock(A)...lock-s(B)...unlock(B)...lock-s(c)...unlock(C)... # 五、多版本并发控制 -（Multi-Version Concurrency Control, MVCC）是 MySQL 的 InnoDB 存储引擎实现隔离级别的一种具体方式，它的基本思想是通过保存每个数据行的多个版本，一个事务对数据行做修改时，其它事务可以读取之前的一个版本，并且都是读取相同的版本，从而保证多个事务对同一个数据行读取的结果是一致的。 - -用于实现提交读和可重复读这两种隔离级别。而对于未提交读隔离级别，它总是读取最新的数据行，无需使用 MVCC；可串行化隔离级别需要对所有读取的行都加锁，单纯使用 MVCC 无法实现。 +（Multi-Version Concurrency Control, MVCC）是 MySQL 的 InnoDB 存储引擎实现隔离级别的一种具体方式，用于实现提交读和可重复读这两种隔离级别。而未提交读隔离级别总是读取最新的数据行，无需使用 MVCC；可串行化隔离级别需要对所有读取的行都加锁，单纯使用 MVCC 无法实现。 ## 版本号 @@ -280,9 +278,11 @@ InnoDB 的 MVCC 使用到的快照存储在 Undo 日志中，该日志通过回 ## 实现过程 +以下过程针对可重复读隔离级别。 + ### 1. SELECT -该操作必须保证多个事务读取到同一个数据行的快照。但是也有例外，如果有一个事务正在修改该数据行，那么它可以读取事务本身所做的修改，而不用和其它事务的读取结果一致。 +该操作必须保证多个事务读取到同一个数据行的快照，这个快照是最近的一个有效快照。但是也有例外，如果有一个事务正在修改该数据行，那么它可以读取事务本身所做的修改，而不用和其它事务的读取结果一致。 当开始新一个事务时，该事务的版本号肯定会大于所有数据行快照的创建版本号，理解这一点很关键。 diff --git a/pics/MultiNode-SessionReplication.jpg b/pics/MultiNode-SessionReplication.jpg new file mode 100644 index 00000000..0223bd80 Binary files /dev/null and b/pics/MultiNode-SessionReplication.jpg differ diff --git a/pics/MultiNode-SpringSession.jpg b/pics/MultiNode-SpringSession.jpg new file mode 100644 index 00000000..38d56e2c Binary files /dev/null and b/pics/MultiNode-SpringSession.jpg differ diff --git a/pics/MultiNode-StickySessions.jpg b/pics/MultiNode-StickySessions.jpg new file mode 100644 index 00000000..a7e1c6aa Binary files /dev/null and b/pics/MultiNode-StickySessions.jpg differ diff --git a/pics/cookiedata.png b/pics/cookiedata.png new file mode 100644 index 00000000..a425fca6 Binary files /dev/null and b/pics/cookiedata.png differ