大规模高并发系统一致性直播

大规模高并发系统一致性直播

JEE架构

SSH架构

Web Service

ESB

微服务

微服务团队管理

遇见的不一致问题

ž假如你想要享受生活的随意，只想买个两居，不想让房贷有太大压力，而你媳妇却想要买个三居，还得带花园的，那么你们就不一致了，不一致导致生活不愉快、不协调，严重情况下还会吵架，可见生活中的不一致问题影响很大。

服务化系统中遇到的不一致的问题

ž1、转账 ž2、下订单和扣库存 ž3、同步超时ž4、异步回调超时5、ž掉单 ž6、系统间状态不一致 ž7、缓存和数据库不一致 ž8、本地缓存节点间不一致 ž9、缓存数据结构不一致

酸碱平衡原理

酸碱平衡 – 酸（ACID）

žA: Atomicity，原子性 žC: Consistency，一致性 žI: Isolation，隔离性 žD: Durability，持久性

酸碱平衡 – 帽子（CAP）žC：Consistency，一致性, 数据一致更新，所有数据变动都是同步的 žA：Availability，可用性, 好的响应性能，完全的可用性指的是在任何故障模型下，服务都会在有限的时间处理响应 žP：Partition tolerance，分区容错性，可靠性

酸碱平衡 – 碱（BASE）žBA：Basically Available，基本可用 žS：Soft State，软状态，状态可以有一段时间不同步 žE：Eventually Consistent，最终一致，最终数据是一致的就可以了，而不是时时保持强一致

分布式一致性协议

两阶段

三阶段

TCC

最终一致性

查询模式

补偿模式

异步确保模式

定期校对模式

定期校对模式

可靠消息模式

缓存一致性模式1、ž缓存是用来加速的，牺牲了一致性，获得高性能，只适合特殊场景； ž ž2、保持数据库和缓存的强一致性是个伪命题 ；ž ž3、如果性能要求不是非常的高，尽量使用分布式缓存，而不要使用本地缓存 4、种缓存的时候一定种完全，如果缓存数据的一部分有效，一部分无效，宁可放弃种缓存，也不要把部分数据种入缓存； 5、通常情况下读的顺序要先缓存，后数据库，写的顺序要先数据库，后缓存。

微服务交互模式

同步调用

受理模式

消息模式

同步与异步的抉择

1、ž尽量使用异步来替换同步操作； ž ž2、能用同步解决的问题，不要引入异步化。

同步两状态接口超时

同步三状态接口超时

异步接口超时

异步内部超时

异步回调超时

消息队列发送超时

消息队列接收超时

超时补偿原则

生活案例：

模式：

ž1、服务1调用服务2，如果服务2响应服务1，并且告诉服务1消息我接收了，那么服务1就的任务就结束了，如果服务2处理失败，服务2应该负责重试或者补偿。在这种情况下，服务2通常先持久消息后再告诉服务1接收成功，随后服务2才开始处理持久的消息，避免服务进程被杀掉丢失消息的情况。  2、服务1调用服务2，如果服务2没有给出明确的接收响应，那么服务1应该持续尝试重试，直到服务2明确表达已经接收消息。这种情况下，容易出现消息重复，因此在服务2中通常要保证滤重或者幂等性。

其他问题

迁移开关的设计

ž1、不要用统一配置开关 ž； ž2、不要用节点内独立的开关 ；ž ž3、迁移开关必须使用订单开关 ž； 4、ž开关要有权限控制 ž； ž5、开关要能开能关。

如果你想成为优秀的架构师在【云时代架构】精品群免费进！我在【云时代架构】技术社区，你在哪里？还等什么，赶快加入【云时代架构】技术社区！请猛扫下面二维码。云时代架构