TCC柔性事物简介

首先业务系统 和 联银平台 是HTTP 跨网络的
所以说HTTP请求 响应必须要快

所以只要我们联银平台接受到业务系统的数据了，直接存储到库中，也就是数据要落地

只要校验通过、数据落地了 我们就保证了业务系统这个请求不会丢失

不管怎么样 先给业务系统返回 个结果 就是消息接受了 或者拒绝了

然后 继续走， 入库之后 我们代码继续写

producer。send（msg）到MQ

返回true 则表示投递成功了 不处理

返回false 可能是MQ 挂了 可能也是网络原因 等等

然后就用一张表记录一下消息投递失败的记录

TCC中也叫失败表 fail

然后这表里同时记录下fail count

如果投递了10次 当然会有时间间隔了

告诉业务系统 消息跪了。。

这仅仅是生产者的消息投递策略

消费者更复杂些。

第一次返回就是表示接受了数据了

第二次返回的就是失败的数据

处理失败了返回就可以了

业务系统可以重新发指令给中心

业务系统要得到MQ消费的返回值。

还得写消费者那边。。还得画消费者那边的东西

这种方式 好处在于。

业务系统直接不需要等待漫长的HTTP网络问题 回送响应很快

然后就不管了

中心平台自己去做投递消息

为啥非得用HTTP

不能业务系统直接发producer。send到MQ

其实就是为了解耦 业务系统不关心你用啥MQ 给我接口我调用就可以

万一后期MQ换了 中心系统代码重构即可

业务系统接口不需要变

而且可以对接N个业务系统

不然你一个业务系统得写一个producer。send

为啥不直接操作原始的表 加一个标识？ 非得再来一张表？

因为 update操作 在高并发下性能损耗特别大

高并发下 insert操作 性能最好

因为update 会有rudo日志 会记录旧的信息 insert则并不会

消息投递成功了就成功了 不需要记录任何成功信息 只需要记录失败记录 重新处理就好了

成功你记录啥用没有。。

失败的信息才是你后续要操作的

有同学又问了

你消息失败表 也要 更新 failcount

也就是失败次数

不也一样么

其实并不一样
因为失败的数据肯定比较少，或者说偶尔会有，我可以允许记录少的表做update 但是在大表 也就是基础表中做update 性能损耗太大

这个是大表

所有的消息信息都会记录这里
失败表数据肯定是少量的

可以容忍update

这些都是基础 和细节

我面试 都是问这种细节 和基础