天猫双十一是怎么保证高并发、分布式系统中，数据一致性的？

淘宝大量使用分布式，但是怎么保证在高并发的时候，数据一致性的。包括分布式、和库存修改加锁模式等等。

郁白 · 2018-9-22 00:57:48

谢邀
今年交易库应该使用的还是全程参与过的Oceanbase0.5版，还可以回答一下

1. 数据一致性的保证，这是个分布式问题，解决方法就是就是Paxos协议。Oceanbase的updateserver节点由一个master和两个slave组成，每条redolog都要保证写master本地成功，并且任意一个slave确认持久化成功才算成功，否则不应答客户端。工程实现上经过了简化，比较类似raft，slave只能应答ID连续的日志同步，而不是megastore里那样，来一条就持久化一条（OB1.0是完美的Multi-Paxos，以后我单独分享blog）。相对与mysql/oracle主备同步要在Maximum Protection和的Maximum availability之间取舍设计，Paxos最大的优势在于，3台机器任意宕掉一台（或者说N台机器任意宕掉N/2台），剩下的机器可以继续提供服务，而不必担心丢失日志。

2. 分库分表事务怎么办，OB的事务都在单点updateserver上执行没有分布式事务问题，由于交易库压力巨大，OB也部署了多个集群，但是交易库的特性是没有跨域交易的事务，因此尽管有一笔交易内的跨表事务，但是业务可以按照交易ID来分库，库与库之间没有事务操作。至于其他业务跨库事务，是靠业务逻辑处理实现事务的。

3. 库存加锁是个好问题，OB和mysql优化方式不太一样，本质是都是批处理，之前是听说mysql通过将多条扣减库存的sql合并为一条sql来优化的，优化逻辑需要处理sql解析，个人感觉比较定制化，后续优化成什么样就不太清楚了；而OB使用了多个优化设计：（1）对于并发扣减库存的语句，引入了一种叫做“early lock release”的机制来优化，在事务提交前释放行锁，使得对同一行的修改有可能能够在一次group commit提交；（2）扩充了sql语法增，类似存储过程，使得insert,update能够在一次auto commit中完成，避免了持锁与客户端交互；（3）支持hint提示，让客户端能够提示可能的冲突，使得我们可以将可能冲突的请求在一个线程中排队处理。如上几个优化效果很显著，但是比较遗憾是，由于某些原因，OB当年没有拿下库存中心，后续才转而主攻更核心的交易库。

iunknown · 2018-9-22 00:57:50

阿里的微博说是用了oceanbase。

ob提到用了paxos，但是看下面这个链接的描述，有点名不符实
http://www.chinacloud.cn/upload/2014-10/14102107296357.pdf

这个链接中描述的算法，日志本身用的应该是类似mysql的semisync吧。然后用一个修改过的paxos来选主，但这个修改后的paxos依赖ntp服务的可靠性。这个等于把paxos的好处都丢掉了。

后端程序员 · 2018-9-22 00:57:53

要让任务尽快得到计算资源。
提高单机计算速度；增加可同时运行的计算资源。
对同时被计算的数据要做数据的一致性处理。

王冬冬 · 2018-9-22 00:57:54

涨姿势了谢楼主

天猫双十一是怎么保证高并发、分布式系统中，数据一致性的？

4 个回复