业务方的倔驴们岂是能随便说服的？ 看场景。资金类，账户类操作很少有柔性事务。如果有，那说明系统拆分得不太合理。或者设计不合理。 是强一致性还是柔性事务，最关键的是：业务容忍度>性能与可用性权衡>系统复杂度成本 1\强一致性场景：业务不允许任何数据不一致 2\柔性事务场景：业务可容忍短暂不一致 能妥协到什么程度就妥协到什么程度，剩下妥协不了的，那就只能部分牺牲了 不可能三角：业务强一致性。高性能。多系统联动。 所以还是BASE最终一致性。我有时候都感觉技术的发展迭代，都是技术人自己给自己挖坑，然后再找新技术来不断填坑的过程。一个新技术引入带来问题，然后又用更新的技术来解决新问题。 听的最多的就是，不管性能、好用与否，按客户的来，先把功能实现能用就行，其他的放到二期、三期再说 最科学的是算财务账，哪种成本低就选哪种。 从技术或者业务单个角度都无法做好选择；... 展开详请

重写 重构是-1到1，需要阅读历史代码来改，结合文档来改 重写是0到1，只需要读懂文档来改 经济政治角度 看有没有钱，有没有人，有没有时间，有没有决策者支持。 有就重写，没有就重构。 其实重写不难，验证太难了。对于业务性质的产品，验证比开发工作量多几十倍 文档角度 文档齐全的， 重写 文档不齐的，只能重构... 展开详请

提到 数据一致性 ，分为强一致性，最终一致性； 强一致性 很容易对应到分布式事务对数据一致性的保证，各种模式，seata框架。 框架很完整，但是落地成本高，对软件系统的性能和吞吐量影响也大； 最终一致性就是各种补偿，事后对比过程数据一致； 很多公司都会采用这种，站在已经发生的事情上，后面做补偿，难度没那么高，也不影响软件系统核心业务的性能和吞吐量； 只要业务方满意，不违背商业本质，数据一致性用啥方式都行。 数据一致性 跟这个相关的还有CAP理论中的C(一致性)。还有就是对软件系统做设计的时候， AP 还是CP的决策； 1. 强调一致性（CP系统） 场景示例：银行系统的账户余额管理 银行账户数据必须保证严格一致，任何时候查询账户余额，都要保证是最新且准确的数据。系统网络发生分区时，不能因为保证可用性而返回错误余额，宁愿拒绝服务或等待恢复。 决策： 优先保证一致性和分区容错性，牺牲部分可用性。 例如：使用分布式锁或共识算法（如Paxos、Raft）来确保数据一致。 2. 强调可用性（AP系统） 场景示例：社交媒体点赞计数 点赞数即使有短时间的不一致也不会造成严重影响，用户体验更重视响应速度和系统持续可用。即使发生网络分区，系统也会继续响应请求，稍后同步数据。 决策： 优先保证可用性和分区容错性，允许短暂的数据不一致。 例如：使用最终一致性模型，异步数据同步和冲突解决机制。 感觉这个是个投资回报率的问题，追求绝对的一致往往要付出巨大的成本，在业务容忍的范围内选择性能、成本、可用性的平衡，才能最大化回报率； 设计分层的一致性策略： 核心账务：强一致 用户行为：最终一致 统计分析：弱一致... 展开详请