本文主要是介绍连锁企业如何通过OceanBase解决数据库瓶颈，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
本文来自OceanBase客户，重庆三十七度健康管理有限公司的技术负责人Rinvay的分享
背景
足疗养生对于大家来说应该并不陌生，自古以来便有多部古籍记载。尽管现代生活中，人们可能不再严格遵循节气进行泡脚，但在忙碌的工作间隙，许多人仍会选择足疗等养生方式，以舒缓身心，缓解疲劳。
如今大多数人已经接受自己的基础信息被录入商家系统，却想不到一个简单的支付动作或会员查询请求背后涉及多么复杂的数据管理系统。
重庆三十七度健康管理有限公司（以下简称“三十七度”）是一家致力于为客户提供品质养生体验与惬意生活的公司，足疗就是该公司旗下品质养生的一部分业务，客户管理系统使用了MySQL、PostgreSQL、MongoDB这三个数据库，用来管理会员卡与储值卡。
门店扩张带来三个系统瓶颈
随着三十七度旗下品牌和门店的不断扩张，公司内部对数据的要求以及对安全的要求越来越高，系统逐渐显露出许多问题。举个例子，由于每天订单信息等数据不断累积，数据总量达到100GB后，单机备份无法实现，使用MySQL做备份的时候由于I/O及其他问题，导致系统运行有几分钟甚至几十分钟的停滞。前台提交的请求比如交易、支付等都会报告异常。对此，技术团队尝试采用MySQL主从复制将数据库实时复制后在另一台设备进行备份，尝试了Binlog及GTID的方式，但该方案在意外停机或者一些异常情况下，导致GTID或Binlog出现异常无法对齐，同步失败，备份失效。
在这个例子中，涉及三个系统瓶颈。
瓶颈1，备份困难。MySQL备份的难点主要体现在数据量较大时备份效率低下的问题。MySQL备份通常采用物理备份或逻辑备份的方式进行，但是在备份过程中，会出现锁表、卡顿等现象，导致备份效率低下，同时也会对业务产生影响。随着门店的数据量不断增加，，数据以几何增长堆积到决策系统，安全备份就成了空谈。
瓶颈2，数据丢失。在随机读写过程中，MySQL可能会发生异常关闭，导致数据丢失，而且系统无法快速恢复服务，需要做容灾处理，比如多活。但是，MySQL不自带多活能力，需要借助第三方工具，不仅配置麻烦，也会带来额外的资源消耗。
瓶颈3，高可用困难。MySQL高可用方案包括主从复制、半同步复制、MHA、MySQL Cluster等，但是这些方案都存在各自的问题。例如，主从复制可能会出现数据不一致的问题，半同步复制可能会导致写入性能下降，MHA的自动切换可能会出现误判等问题，MySQL Cluster的性能和扩展性也存在瓶颈。因此，MySQL在高可用方面的解决方案不够完善，需要借助第三方工具，增加了配置和维护的难度。
由于三十七度计划自研新CRM客户管理系统和商城模块，并与收银系统进行打通，便开始寻求新的数据库解决方案。
寻求稳定而高效的数据库解决方案
我们在考虑数据库选型时，曾经考虑过PostgreSQL和TiDB等数据库，但最终选择了OceanBase。”团队技术负责人Rinvay坦言，相对于PostgreSQL和TiDB等数据库，OceanBase具有以下优势：
- 高可用性：OceanBase自带多活能力，可以实现业务的高可用性，而TiDB的高可用性需要借助TiDB的PD、TiKV等组件，增加了系统的复杂度和维护成本。
- 扩展性：OceanBase采用分布式架构，可以根据业务需求灵活扩展节点，而TiDB的扩展性受限于PD和TiKV的性能和扩展性。
- 兼容性：OceanBase与MySQL的语法基本相同，可以实现无缝迁移，降低了公司的学习成本，而PostgreSQL和TiDB的语法与MySQL略有不同，需要重新学习。
三十七度最终选择了OceanBase作为新系统的数据库，因为它能够为企业提供更加稳定和高效的数据库解决方案，同时也能够满足公司的业务需求。
线上部署过程中的小插曲
在选定数据库后，三十七度技术团队开始针对OceanBase的部署进行学习研究，得益于OceanBase社区的完善以及部署脚本等大多都是一键部署的关系，团队很快就在本地机房搭建了一套基于OCP管理的OceanBase数据库，进行了核心业务的开发。
当然，在开发过程中，也遇到了很多问题。
问题1：分区数量过多。订单明细表每天都有上百万条数据，以至于分区数量达到8000个左右，导致表增改字段操作速度慢，语句执行失败。此时，唯一的办法是在后台删除进程或避免该操作。经过重新制定分区策略后（将数据备份，删掉分区并重建），目前分区数量降至200个。每个分区的数据量约500万条，卡顿问题就很少出现了。经过深入排查分析之后，得出结论：大概率是因为机器资源紧张而分区数过多导致（单机8c 16g）的。
问题2：OceanBase 4.0备份机制已知Bug。在测试时，三十七度使用的是OceanBase 3.x版本，上线4.0版本后，使用OCP增加备份策略一直未能成功。原因是备份时需要自动执行，如果选择“不执行”则报错，提示缺少admin文件，团队架构师刘亿谈到。计划升级到4.1版本再做备份，OceanBase在线升级不用停机，不会对业务造成影响。
问题3：连接驱动问题。使用JDBC2.4版本无法连接OBProxy，但可以连接三节点集群，或使用JDBC v3.0也可以连接OBProxy。
对于这些问题，我们也得到了OceanBase社区版的支持和帮助，历时一年半完成了整套系统的研发和测试，在2023年的3月份正式启动上线并成功完成上线。线上部署主要采用了三个OceanBase节点，使用OCP进行集群管理维护及告警提醒等，还采用了OBProxy进行访问代理。目前日活跃用户超过5万，日订单及其他数据承载量为15-20万单，注册/转移会员超过50万，借助OceanBase的强大驱动力，三十七度正在用技术的力量一点点改变世人对足浴行业的固有认知，让智能和健康与足浴于大健康相互绑定相互衬托。
总结与展望
对于后续计划，三十七度会将现有系统升级为支持主备的OceanBase 4.1版本，并将旧业务也迁移至新系统。
2023年是AI技术元年，随着AI技术的不断进步，有一个稳定的数据库大后方为我们的数据提供强有力的支撑才能让‘Chat‘们在用户手中开出花。我们有理由相信有着这样一支以‘打造极致体验感‘为理念的团队支撑三十七度不断前行，一定能为客户带来更优秀的体验。也相信依托OceanBase 的独特技术优势和成为国之重器的决心，一定能在未来的合作中碰撞出更多智慧的火花。
这篇关于连锁企业如何通过OceanBase解决数据库瓶颈的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
