好系统都是设计出来的，不过数据库厂商最好让应用设计变得更简单

今天回程高铁上我就在想前几天携程关于OB读写分离实践的那个案例，想把我想到的这个案例的意义拿出来和大家分享一下。 经常有人谈到因为某某数据库的问题而导致了系统问题的时候，总有人会说“好的系统都是设计出来的”。几年前和Oracle研发的一个座谈会上，当时Oracle研发方面的总监说：“Oracle的目标是让在座的开发者设计应用系统的时候变得更加简单。”。所以说虽然好的系统都是设计出来的，我们的数据库厂商最好还是能够“让设计变得更为简单”。 数据库的核心肯定是让数据的存储、管理、访问更加便捷，数据的存储更加安全，不过除了做好数据库的核心之外，数据库呈现给大家的接口也应该让应用开发者更为便捷，因此多听听用户的意见总是好的。现在的国产数据库种类繁多，大家内卷的也很厉害，比SQL语句执行比Oracle快多少倍已经不是国产数据库PK的主战场了，有的数据库可以充分利用GPU/FPGA进行AI计算，有的数据库可以使用硬件加密卡加密压缩数据。实际上玩这些噱头都没什么意思，大多数客户的基本需求并不是这些小众功能。有一次和一个数据库厂家沟通的时候，他问我，如果我选两个最需要的功能，你希望国产数据库有什么能力，我的回答是高可用和与Oracle的兼容性。高可用是确保我们应用的最基础的保障，而绝大多数数据库目前正在从Oracle迁移过来，我们的大部分开发厂商也在Oracle上积累了大量的研发能力，如果能够在语法，使用等方面与Oracle保持较好的兼容，对于企业数据库系统的国产化替代来说，可以节约大量的资金。 前几天携程的朋友分享了一个OceanBase读写分离实践的案例，我看了之后深有同感，这是一个相当好的数据库读写分离的应用案例。大多数分布式数据库都会使用多副本，而副本之间的数据同步是异步的，因此主要的读写都集中在主副本上，对其他副本的读写需要考虑强一致性的要求，否则可能会读到不一致的数据。而有很多业务，比如统计分析、查询历史数据等，并不需要数据是十分实时的，因此读取弱一致性的副本就可以确保业务正确了。这种弱一致性读取的方法在大多数读写分离的复制集群中都可以使用。只不过大部分数据库都通过添加hint的方式来判断某条SQL是否运行读取可能存在数据复制延迟的副本时是否存在问题。 在开发时强制要求添加HINT当然也是一种可以实现的方式，不过这对于开发团队执行能力提出了比较高的要求，如果有更简单的方法来实现此类的自动化分析，那肯定是更好的。

携程的团队根据自身的业务特点，通过修改obproxy，设计了参数weak_read_user_list来指明通过某些数据库用户登录的应用是否允许弱读一致性。可以通过只读副本读取的应用模块都通过某些特定的用户登录。而且登录到特定的IDC的OBPROXY上（通过PROXY_IDC_NAME确定），这样在应用程序中就不需要再去留意HINT了。 在大家的交流讨论中，我也建议蚂蚁把携程的这个参数收录到OB的主版本中去。实际上我们还可以做的更加完善一些，携程的业务模块开发比较规范，不同的业务模块可以连接不同的数据库用户。而对于一些开发能力稍弱的开发商，这个参数还不够用，还可以增加一个wead_read_module_list，定义某个模块可以使用弱一致性的只读副本来完成读取。数据库在客户端提供一个db_client_info的函数包，可以通过db_client_info.set_module来设置自己的模块名称。这样只要在开发框架中添加了Module名称自动设置的代码后，这部分的开发就变得简单起来了，开发人员根本不需要了解访问的数据是否是弱读一致性的还是强一致性的了。 其实，目前国产数据库厂商能够给我们的客户做的事情还相当多，只不过目前数据库厂商与客户之间的沟通渠道还不够畅通，或者说我们的数据库厂商还没有开始充分的聆听客户的需求，因此这些能够让应用开发变得更为简单的功能还没有成为数据库厂商在产品研发时的优先研发功能。我们的数据库厂商可能还是把过多的精力放在了如何再提高一点TPMC测试的成绩上了。实际上这种类似于当年美苏军备竞赛的工作的价值远远没有OB开发人员把携程的实践经验纳入到OBPROXY的主版本中那么大。