auto commit

notes/Git.md

@@ -79,7 +79,7 @@ Git 把每次提交都连成一条时间线。分支使用指针来实现，例
 
 # 冲突
 
-当两个分支都对同一个文件进行了修改，在分支合并时就会产生冲突。
+当两个分支都对同一个文件的同一行进行了修改，在分支合并时就会产生冲突。
 
 <div align="center"> <img src="../pics//58e57a21-6b6b-40b6-af85-956dd4e0f55a.jpg"/> </div><br>
 

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
+<div align="center"> <img src="../pics//cookiedata.png"/> </div><br>
 
-### 原理
+## 1. Sticky Sessions
 
-粘性 Session 是指将用户锁定到某一个服务器上，比如上面说的例子，用户第一次请求时，负载均衡器将用户的请求转发到了 A 服务器上，如果负载均衡器设置了粘性 Session 的话，那么用户以后的每次请求都会转发到 A 服务器上，相当于把用户和 A 服务器粘到了一块，这就是粘性 Session 机制。
+需要配置负载均衡器，使得一个用户的所有请求都路由到一个服务器节点上，这样就可以把用户的 Session 存放在该服务器节点中。
 
-### 优点
+缺点：当服务器节点宕机时，将丢失该服务器节点上的所有 Session。
 
-简单，不需要对 Session 做任何处理。
+<div align="center"> <img src="../pics//MultiNode-StickySessions.jpg"/> </div><br>
 
-### 缺点
+## 2. Session Replication
 
-缺乏容错性，如果当前访问的服务器发生故障，用户被转移到第二个服务器上时，他的 Session 信息都将失效。
+在服务器节点之间进行 Session 同步操作，这样的话用户可以访问任何一个服务器节点。
 
-### 适用场景
+缺点：需要更好的服务器硬件条件；需要对服务器进行配置。
 
-- 发生故障对客户产生的影响较小；
-- 服务器发生故障是低概率事件。
+<div align="center"> <img src="../pics//MultiNode-SessionReplication.jpg"/> </div><br>
 
-## 2. 服务器 Session 复制
+## 3. Persistent DataStore
 
-### 原理
+将 Session 信息持久化到一个数据库中。
 
-任何一个服务器上的 Session 发生改变，该节点会把这个 Session 的所有内容序列化，然后广播给所有其它节点，不管其他服务器需不需要 Session，以此来保证 Session 同步。
+缺点：有可能需要去实现存取 Session 的代码。
 
-### 优点
+<div align="center"> <img src="../pics//MultiNode-SpringSession.jpg"/> </div><br>
 
-可容错，各个服务器间 Session 能够实时响应。
+## 4. In-Memory DataStore
 
-### 缺点
-
-会对网络负荷造成一定压力，如果 Session 量大的话可能会造成网络堵塞，拖慢服务器性能。
-
-### 实现方式
-
-1. 设置 Tomcat 的 server.xml 开启 tomcat 集群功能。
-2. 在应用里增加信息：通知应用当前处于集群环境中，支持分布式，即在 web.xml 中添加&lt;distributable/> 选项。
-
-## 3. Session 共享机制
-
-使用分布式缓存方案比如 Memcached、Redis，但是要求 Memcached 或 Redis 必须是集群。
-
-使用 Session 共享也分两种机制，两种情况如下：
-
-### 3.1 粘性 Session 共享机制
-
-和粘性 Session 一样，一个用户的 Session 会绑定到一个 Tomcat 上。Memcached 只是起到备份作用。
-
-<div align="center"> <img src="../pics//93a28704-6401-4671-9758-051fadfbeb47.jpg" width="400"/> </div><br>
-
-### 3.2 非粘性 Session 共享机制
-
-#### 原理
-
-Tomcat 本身不存储 Session，而是存入 Memcached 中。Memcached 集群构建主从复制架构。
-
-<div align="center"> <img src="../pics//ce0fa5d0-866b-46e6-a873-8eb1f78c2882.jpg" width="400"/> </div><br>
-
-#### 优点
-
-可容错，Session 实时响应。
-
-#### 实现方式
-
-用开源的 msm 插件解决 Tomcat 之间的 Session 共享：Memcached_Session_Manager（MSM）
-
-## 4. Session 持久化到数据库
-
-### 原理
-
-拿出一个数据库，专门用来存储 Session 信息。保证 Session 的持久化。
-
-### 优点
-
-服务器出现问题，Session 不会丢失
-
-### 缺点
-
-如果网站的访问量很大，把 Session 存储到数据库中，会对数据库造成很大压力，还需要增加额外的开销维护数据库。
-
-## 5. Terracotta 实现 Session 复制
-
-### 原理
-
-Terracotta 的基本原理是对于集群间共享的数据，当在一个节点发生变化的时候，Terracotta 只把变化的部分发送给 Terracotta 服务器，然后由服务器把它转发给真正需要这个数据的节点。它是服务器 Session 复制的优化。
-
-<div align="center"> <img src="../pics//b6acae0d-7148-41de-adc3-ff5ff8dca3ae.jpg"/> </div><br>
-
-### 优点
-
-这样对网络的压力就非常小，各个节点也不必浪费 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)

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
 
-该操作必须保证多个事务读取到同一个数据行的快照。但是也有例外，如果有一个事务正在修改该数据行，那么它可以读取事务本身所做的修改，而不用和其它事务的读取结果一致。
+该操作必须保证多个事务读取到同一个数据行的快照，这个快照是最近的一个有效快照。但是也有例外，如果有一个事务正在修改该数据行，那么它可以读取事务本身所做的修改，而不用和其它事务的读取结果一致。
 
 当开始新一个事务时，该事务的版本号肯定会大于所有数据行快照的创建版本号，理解这一点很关键。