一 序：
本文是公司技术学院讲课的笔记，有沈剑老师主讲。欢迎扫一扫关注沈老师公众号：架构师之路
一致性是互联网公司的常见话题，是业务架构中必须考虑的点之一。
二 session一致性
因为数据存在冗余会引发一致性问题。
业务场景：session信息不存在，会要求用户登录。
单节点：不存在session一致性问题。
多节点情况： 1.数据互相同步（优点不改代码，缺点：扩容难 ，不推荐）
2 。保存数据从server端转移到客户端（很少用，一种思路）。
3. 分到同一个节点（NGINX 负载均衡分发到一台，缺点：机器有变化还会有波动）
4. 数据下沉到云端（redis等），程序不关心，从redis获取数据，不收节点变动影响。
三 主从一致性：
常见场景：读多写少，所以为了减轻主库压力，采用一主多从，读写分离模式。
问题case： 写后立即读。
主从同步方式：binlog.这是基于写操作日志的。顺序很重要。
不能并发提高效率，对应优化点：降低锁粒度，比如一个数据库有不同表，多个表并行，每个表串行。
相关知识点：dts,cannal.
细节可以看公众号文章： 架构师之路
优化方案如下：
方案一（半同步复制）
不一致是因为写完成后，主从同步有一个时间差，假设是500ms，这个时间差有读请求落到从库上产生的。有没有办法做到，等主从同步完成之后，主库上的写请求再返回呢？答案是肯定的，就是大家常说的“半同步复制”semi-sync：
（1）系统先对DB-master进行了一个写操作，写主库
（2）等主从同步完成，写主库的请求才返回
（3）读从库，读到最新的数据（如果读请求先完成，写请求后完成，读取到的是“当时”最新的数据）
方案优点：利用数据库原生功能，比较简单
方案缺点：主库的写请求时延会增长，吞吐量会降低
方案二（强制读主库）
如果不使用“增加从库”的方式来增加提升系统的读性能，完全可以读写都落到主库，这样就不会出现不一致了：
方案优点：“一致性”上不需要进行系统改造
方案缺点：只能通过cache来提升系统的读性能，这里要进行系统改造
方案三（数据库中间件）
如果有了数据库中间件，所有的数据库请求都走中间件，这个主从不一致的问题可以这么解决：
（1）所有的读写都走数据库中间件，通常情况下，写请求路由到主库，读请求路由到从库
（2）记录所有路由到写库的key，在经验主从同步时间窗口内（假设是500ms），如果有读请求访问中间件，此时有可能从库还是旧数据，就把这个key上的读请求路由到主库
（3）经验主从同步时间过完后，对应key的读请求继续路由到从库
方案优点：能保证绝对一致
方案缺点：数据库中间件的成本比较高
方案四（缓存记录写key法）
既然数据库中间件的成本比较高，有没有更低成本的方案来记录某一个库的某一个key上发生了写请求呢？很容易想到使用缓存，当写请求发生的时候：
（1）将某个库上的某个key要发生写操作，记录在cache里，并设置“经验主从同步时间”的cache超时时间，例如500ms
（2）修改数据库
而读请求发生的时候：
（1）先到cache里查看，对应库的对应key有没有相关数据
（2）如果cache hit，有相关数据，说明这个key上刚发生过写操作，此时需要将请求路由到主库读最新的数据
（3）如果cache miss，说明这个key上近期没有发生过写操作，此时将请求路由到从库，继续读写分离
方案优点：相对数据库中间件，成本较低
方案缺点：为了保证“一致性”，引入了一个cache组件，并且读写数据库时都多了一步cache操作
四 主主 一致性
主从的一个缺点：单主不能保证高可靠。双主保证高可用，提高写入速度。
风险：key冲突，丢失数据。
优化方案：1 设置数据库相同步长，不同的起始值（优点：不改代码，缺点：不易扩展）
2.业务生成唯一id（类似于sonwflake）
3. 内网dns探测机制（为了保证数据同步时延，比如500ms后同步完在进行切换）
其他开源框架待补充。
五 缓存一致性：
引入缓存目的：提高效率，减少数据库读压力。
原则：不能因为引入缓存导致不一致（比主从同步的时延更有危害）
读操作： 先读缓存，命中直接返回，不命中回源查库后，把结果更新缓存。
写操作：先淘汰缓存，再写数据库。
不一致产生case：
分布式情况下，对同一个数据进行读写，在数据库层面并发的读写并不能保证完成顺序，也就是说后发出的读请求很可能先完成（读出脏数据）：
（a）发生了写请求A，A的第一步淘汰了cache（如上图中的1）
（b）A的第二步写数据库，发出修改请求（如上图中的2）
（c）发生了读请求B，B的第一步读取cache，发现cache中是空的（如上图中的步骤3）
（d）B的第二步读取数据库，发出读取请求，此时A的第二步写数据还没完成，读出了一个脏数据放入cache（如上图中的步骤4）
即在数据库层面，后发出的请求4比先发出的请求2先完成了，读出了脏数据，脏数据又入了缓存，缓存与数据库中的数据不一致出现了
优化方案：二次淘汰
方案1 ：阻赛写入
延时500ms更新缓存，缺点：业务性能下降严重。
方案2： 加入异步timer：如dmq延时淘汰缓存。
方案3： 基于binlog做异步淘汰。
还补充一个数据冗余保存多份数据一致性的case。
订单中心多个维度：orderid，buerid,sellerid
对于这种冗余多个库，一致性原则：那个对业务影响小优先，其余的同步对比后手段弥补。
***************************************
其余的下一讲。