Henry Z's blog
·
读《数据密集型应用系统设计》
内容提要
在阅读《数据密集型应用系统设计》时，回忆起在蚂蚁工作时遇到的两个故障：第一个因RPC反序列化错误导致支付失败，因新枚举未识别；第二个因数据库bug导致支付请求失败，因代码强依赖数据库时间。通过改进代码和理解数据库机制，成功解决了这些问题。
关键要点
-
在阅读《数据密集型应用系统设计》时，回忆起在蚂蚁工作时遇到的两个故障。
-
故障1：因RPC反序列化错误导致支付失败，因新枚举未识别。
-
故障1的原因是应用B新增枚举，导致应用A反序列化失败。
-
解决方案包括：1）遇到未知枚举值时fallback到UNKNOWN；2）避免使用枚举，通过字符串交互。
-
故障2：因数据库bug导致支付请求失败，因代码强依赖数据库时间。
-
故障2的根因是get_or_create_user服务在准备时请求数据库获取当前时间。
-
通过修改代码为懒加载模式解决了故障。
-
书中介绍了分布式数据库的三类：Single leader、Multi leader和Leaderless。
-
OceanBase采用基于Paxos协议的多副本同步机制，确保数据一致性。
延伸解读
故障分析与解决策略
在处理故障时，了解其根本原因至关重要。文章中提到的RPC反序列化错误和数据库bug，强调了系统间的兼容性和依赖性。通过设置fallback机制和懒加载模式，可以有效降低故障发生的概率，提升系统的稳定性。
分布式数据库的选择
文章提到的分布式数据库类型（Single leader、Multi leader、Leaderless）各有优缺点。在选择数据库架构时，需考虑数据一致性和系统性能的平衡。OceanBase采用的Paxos协议确保了数据的高一致性，适合对数据可靠性要求高的应用场景。
编码与数据演化的挑战
在数据密集型应用中，编码方式的选择直接影响系统的可扩展性和维护性。使用protobuf等高效编码方式可以提高性能，但也要求开发者在版本演化时谨慎处理兼容性问题，以避免因新枚举值导致的反序列化错误。
延伸问答
在《数据密集型应用系统设计》中提到的故障是什么？
提到的故障包括因RPC反序列化错误导致支付失败和因数据库bug导致支付请求失败。
如何解决RPC反序列化错误的问题？
可以通过在遇到未知枚举值时fallback到UNKNOWN，或避免使用枚举，通过字符串交互来解决。
第二个故障的根本原因是什么？
第二个故障的根本原因是get_or_create_user服务在准备时请求数据库获取当前时间，导致强依赖数据库。
OceanBase数据库的同步机制是什么？
OceanBase采用基于Paxos协议的多副本同步机制，确保数据一致性。
在设计数据密集型应用时需要注意哪些兼容性问题？
需要谨慎考虑向前和向后兼容，尤其是在数据结构变更时。
为什么不直接在数据库中使用now()来表示当前时间？
不使用now()是为了遵循“确定性&一致性”的最佳实践，确保时间的正确性和副本间的同步一致性。
