罗彬桦的博客

基于MQ（RocketMQ的安装）rocketmq.apache.orgwindows的安装记住下载4.5.2版本的，不然会报错目录启动： > nohup sh bin/mqnamesrv & > tail -f ~/logs/rocketmqlogs/namesrv.log The Name Server boot success...windows发现有问题，没有设置home打开电脑高级设置3.4. 修改配置5. 启动队列

基于MQ的最终一致方案原理、流程与本地消息表类似不同点：本地销项表改为MQ不同点：定时任务改为MQ的消费者不依赖定时任务，基于MQ更高效、更可靠适合于公司内的系统不同公司之间无法基于MQ，本地消息表更适合二.各种消息队列优缺点rabbitMqrabbitMq 几万级数据量，基于erlang语言开发，因此响应速度快些，并且社区活跃度比较活跃，可视化界面。缺点就是数据吞吐量相对与小一些，并且是基于erlang语言开发，比较重的问题难以维护rocketMqrocketMq几十万级别

基于本地消息表的最终一致方案基于本地消息表采用BASE原理，保证事务最终一致在一致性方面，允许一段时间内的不一致，但最终会一致在实际的系统当中，要根据具体情况，判断是否采用基于本地消息表的方案中，将本事事务操作，记录在消息表其他事务，提供操作接口定时任务轮询本地消息表，将末执行的消息发送给操作接口操作接口处理成功，返回成功标识，处理失败返回失败标识定时任务接到标识，更新消息的状态定时任务按照一定的周期反复执行对于屡次失败的消息，可以设置最大失败次数超过最大失败次数的消息，不再

事务补偿机制什么是事务补偿机制？针对每个操作，都要注册一个与其对应的补偿（撤销）操作在执行失败时，调用补偿操作，撤销之前的操作A给B转账的例子，A和B在两家不同的银行A账户减200元，B账户加200元两个操作要保证原子性，要么全成功、要么全失败由于A和B在两家不同的银行，所以存在分布式事务的问题转账接口需要提供补偿机制如果A在扣减的过程出现问题，直接抛出异常，事务回滚B在增加余额的过程中，出现问题，要调用A的补偿接口A之前的扣减操作，得到了补偿，进行了撤销保证了A和B的账是没有问题

基于XA协议的两阶段提交XA是由X/Open组织提出的分布式事务的规范由一个事务管理器（TM）和多个资源管理器（RM）组成提交分为两个阶段：prepare和commit第一阶段第二阶段保证数据的强一致性commit阶段出现问题，事务出现不一致，需人工处理效率低下，性能余本地事务相差10倍MySql5.7 及以上均支持XA协议MySql Connector/J 5.0以上 支持XA协议Java系统中，数据源采用Atomikos...

分布式事务的问题传统的应用都是单一数据库事务所有的业务表都在同一数据库内数据库的事务可以很好的得到支持分布式系统中，业务拆分成多个数据库多个独立的数据库之间，无法统一事务造成数据不一致的情况比如：一个下单操作，用户使用积分购买商品用户库扣减积分，订单库生成订单，商品库扣减库存由于它们不在同一数据库，不能保证事务统一基于XA协议的两阶段提交事务补偿机制基于本地消息表+定时任务的最终一致方案基于MQ的最终一致方案...

分布式事务如果将数据库分库分表就会引起事务，操作A数据库和B数据库的数据不同步。分布式ID问题（上一章）CAP原理（只能满足两项）ACID原理与BASE原理基于XA协议的两阶段提交事务补偿机制基于本地消息表的最终一致方案基于MQ消息队列的最终一致方案...

UUIDUUID 通用唯一识别码（Universally Unique ldentifier）使用UUID，保证每一条记录的id都是不同的。缺点：只是单纯的一个id，没有实际意义。长度32位，太长。MyCat不支持UUID的方式Sharding-Jdbc支持UUID方式...

分布式全局id分库分表的系统中，由于id引发的问题使用UUID作为id实现主键全局唯一性保证通过统一ID序列表，实现全局id雪花算法 作为全局id多种方案的比较分库分表引发的id问题每个表都有唯一标识，通常使用idid通常采用自增的方式在分库分表的情况下，每张表的id都从0开始自增不同的分片上，id可能重复导致id在全局不唯一，导致业务上出问题将用户user_id=19和user_id=20的分为两个数据库，那么订单id 4和5两个表都有，那到底是哪个订单呢