转载自：https://www.cnblogs.com/sujing/p/11006424.html
数据库的四大特征：原子性、一致性、隔离性、持久性。
分布式理论
CAP理论，一个分布式系统不可能同时满足一致性、可用性、分区容错性三个基本需求，最多同时只能满足其中两项。
一致性：在分布式系统中，数据在多个副本之间能否保持一致的特性，也就是说对某个数据进行写操作后立马执行读操作，必须能读取到刚刚写入的值。
可用性：任意被无故障节点接收到的请求，必须能够在有限的时内响应结果。
分区容错性：如果集群中的机器被分成了两部分，这两部分不能互相通信，系统是否能继续正常工作。
分布式事务
分布式事务的解决方案有很多，如XA协议、TCC三阶段提交、基于消息队列等等，以下以基于消息队列为例，流程如下：
1、A银行对账户进行检查校验、进行全额扣减，并存到转账流水表；
2、将对B银行的请求异步写入队列，主线程返回；
3、启动后台程序从队列获取待处理数据；
4、后台程序对B银行接口进行远程调用；
5、定期的从转账流水表中读取状态为“待处理”且最后更新的时间距当前时间大于某个阈值的数据，调用B银行处理结果查询接口，若未查到结果则重新放入消息队列进行补偿，若查到则更新该数据状态；
6、B银行对转入账户进行检查校验，根据唯一转账流水Id在转账日志表中查找判断该转账是否已经处理过，若未处理则进行金额增加，并存到转账日志表，否则直接返回日志表处理结果；
7、B银行处理完成后回调A银行接口通知处理结果；
转账流水表设计如下：
| 字段名称 | 字段描述 |
| id | 交易流水id |
| accountNo | 银行账户 |
| targetBankNo | 目标银行编码 |
| targetAccountNo | 目标银行卡号 |
| targetAccountName | 目标银行卡持卡人姓名 |
| amount | 交易金额 |
| status | 交易处理状态（待处理、处理成功、处理失败） |
| createTime | 创建时间 |
| lastUpdateTime | 最后更新时间 |
转账日志表：
| 字段名称 | 字段描述 |
| id | 编号 |
| transId | 交易流水号，对应转账流水表id |
| sourceAccountNo | 源银行账户，对应转账流水表accountNo |
| targetAccountNo | 目标银行卡号，对应转账流水表targetAccountNo |
| targetAccountName | 目标银行卡持卡人姓名，对应转账流水表targetAccountName |
| amount | 交易金额 |
| status | 交易处理状态（处理成功、处理失败） |
| createTime | 创建时间 |
以上A银行通过本地事务保证日志记录+后台线程轮询保证消息不丢失。B银行通过本地事务保证日志记录从而保证消息不重复消费！B银行在回调A银行的接口时会通知处理结果，如果转账失败，A银行会根据处理结果进行回滚。
标签：转账,处理,银行,流水,思考,日志,id,分布式 来源： https://www.cnblogs.com/zlbx/p/11095594.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。