今年交易库应该使用的还是全程参与过的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当年没有拿下库存中心，后续才转而主攻更核心的交易库。
内容全部来源于网络收集，如有侵权，请联系网站删除：QQ：24596024