亿级大表分库分表实战总结( 七 ) _分库分表

1）新表设计必须跟业务方充分沟通、保证review 。
2）对于“数据同步” ，必须有数据校验保障数据正确性，可能导致数据不正确的原因上文已经提到来很多，包括实时性、一致性的问题。保证数据正确是上线的大前提。
3）每一阶段的变动，都必须做好快速回滚都预案。
4）上线过程，都以分批上线的形式，从非核心业务开始做试点，避免故障扩大。
5）监控告警要配置全面，出现问题及时收到告警，快速响应。不要忽略，很重要，有几次出现选过数据的小问题，都是通过告警及时发现和解决的
6）单测，业务功能测试等要充分
6.项目管理之跨团队协作关于“跨团队协作” ，本文专门拎出来作为一章。
因为在这样一个跨团队的大型项目改造过程中，科学的团队协作是保障整体项目按时、高质量完成的不可缺少的因素。
下面，分享几点心得与体会。
6.1 一切文档先行团队协作最忌“空口无凭” 。
无论是团队分工、进度安排或是任何需要多人协作的事情，都需要有一个文档记录，用于追踪进度，把控流程。
6.2 业务沟通与确认所有的表结构改造，必须跟相关业务方沟通，对于可能存在的历史逻辑，进行全面梳理；
所有讨论确定后的字段改造，必须由每个服务的Owner进行确认。
6.3 责任到位对于多团队多人次的合作项目，每个团队都应该明确一个对接人，由项目总负责人与团队唯一对接人沟通，明确团队完整进度和完成质量。
7.展望其实，从全文的篇幅就能够看出，本次的分库分表项目由于复杂的业务逻辑改造，费大量的时间和精力，并且非常容易在改造过程中，引起不稳定的线上问题。
本文复盘了整个分库分表从拆分、设计、上线的整体过程，希望能对大家有所帮助。

看到这里，我们会想问一句。所以，有没有更好的方式呢？
也许，未来还是需要去结合业界新的数据库中间件技术，能够快速实现分库分表。
也许，未来还可以引入新的数据存储技术与方案（polardb、tidb、hbase），根本不再需要分库分表呢？
继续跟进新技术的发展，我相信会找到答案。