沈老师讲课-一致性（上）
一 序：
本文是公司技术学院讲课的笔记，有沈剑老师主讲。欢迎扫一扫关注沈老师公众号：架构师之路redis
一致性是互联网公司的常见话题，是业务架构中必须考虑的点之一。数据库
二 session一致性
由于数据存在冗余会引起一致性问题。缓存
业务场景：session信息不存在，会要求用户登陆。session
单节点：不存在session一致性问题。架构
多节点状况： 1.数据互相同步（优势不改代码，缺点：扩容难 ，不推荐）并发
2 。保存数据从server端转移到客户端（不多用，一种思路）。app
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
对于这种冗余多个库，一致性原则：那个对业务影响小优先，其他的同步对比后手段弥补。
***************************************
其他的下一讲。