本文作者：马琳，万家数科数据库专家。
万家数科商业数据有限公司，作为华润万家旗下的信息技术企业，专注于零售行业，在为华润万家提供服务的同时，也积极面向市场，为零售商及其生态系统提供全面的核心业务系统解决方案及运维服务。核心业务领域涵盖了数据服务与SaaS产品、业务洞察咨询服务、以及精准营销与相关服务。
应对零售业务的技术挑战
华润万家是1984年在香港成立了第一家门店，至今已有40年的历史了。在整体零售业务的发展的过程中，系统从最初简单的进销存系统演变为如今多套系统的配合，比如物流供应链，会员系统、线上业务系统。但由于新老系统的交替运行积攒了各种各样的问题，我们总结为以下四类：
- 多系统并行，导致数据孤岛。
- 用户体验降低，由于线下门店与线上渠道的联动及业务融合，加上用户需求多样化，系统的响应速度与易用性逐渐难以满足用户要求。
- 链路复杂，导致故障排查困难，产生性能瓶颈。
- 系统可扩展性受限。受限于技术架构和成本压力，系统扩展能力较差。
挑战1：多系统并行。
这是一个绕不开的话题，跟随业务发展阶段的演变，系统也从最初的套装系统转变为Java定制开发，使用了多种不同的数据库，如IBM informix、Oracle、MySQL等。不同数据库的差异化非常大，以至于不同团队需要频繁沟通，制定统一交互协议，确保数据流转顺畅，这会耗费大量的时间和精力。
同时，对于各个系统之间的技术架构、数据格式、接口规范差异，也需要定制化开发适配器和中间件，增加了集成难度。长此以往，业务量在增长，各业务系统之间的资源耗费也随之加剧，带来了成本压力，各团队需要合理分配硬件资源、网络带宽，优化系统配置，减少资源冲突，提升整体性能。
挑战2：用户体验降低。
用户体验分为内部用户和外部用户，但总体而言，可以总结为三点要求。
第一，个性化需求。不同用户对系统的功能、界面、操作方式等有不同的需求，满足个性化需求难度较大。
第二，响应速度。用户要求系统的响应速度越来越快，尤其是在高并发情况下，但保证系统的快速响应是一个挑战。
第三，易用性。系统的复杂功能可能导致用户操作困难，降低用户体验。
挑战3：链路复杂。
由于各系统在数据传输过程中存在各种各样的问题。导致故障点难定位，需要经过多环节排查，增加修复时间，而且链路中某环节容易造成瓶颈，影响整体性能，需要优化资源配置。作为运维人员，利用监控手段定位问题，然而某些监控盲点需要一个更强大的运维团队做实时分析，这十分考验监控运维团队对业务的理解能力。
更关键的是复杂链路提升了被攻击的风险，加强安全防护措施，确保系统安全也是需要重点关注的。
挑战4：系统可扩展性受限。
原有的数据库由于其架构特性，难以应对业务增长后带来的性能需求，同时随着系统规模的不断扩展，代码的复杂度增加，导致维护难度加大。如果扩展系统，不仅需要投入大量的资金，还需要大量的人力资源支持，企业要面临的成本压力极大，这也成为了限制企业发展的主要矛盾。
应对策略与具体措施
数科技术团队选择从硬件、操作系统、数据库、开发思想等多方面入手，如硬件选择国产X86、ARM架构；操作系统选择如龙蜥、麒麟等国产可控系统；开发引入领域驱动设计思想（DDD）等，各方面持续优化现有软硬件架构。数据库选择上数科技术团队考察了很多数据库产品。并在调研后选择将原有的数据库替换为原生分布式数据库OceanBase（数据库选型与测评详见博客https://open.oceanbase.com/blog/9690209104）。
引入新技术OceanBase的历程与收益
在2022年6月，万家数科引入OceanBase 3.x版本，并开始POC测试、核心系统验证，直至2022年12月。彼时了解到单机分布式一体化的OceanBase 4.0版本即将发布，便等到新版本发布后及时跟进了系统迁移测试，经过几个月生产环境的上线实践，取得的效果让我们非常满意。在2024年将大批系统迁移到OceanBase数据库，将其作为技术底座。
无论是新项目的生产与开发，还是旧项目的迁移，目前万家数科已有五六十个项目使用OceanBase，未来将有更多的项目建立在OceanBase数据库之上。具体收益总结为以下5点。
- 成本节约：高压缩存储技术，原存储迁移后容量降低约60%，硬件成本节约50%，业务综合成本节约25%左右。
- 资源有效利用率提高：使用集群汇聚多个实例，多租户资源隔离，减少资源碎片，充分利用资源。
- 改善业务韧性，开发效率提升：优化业务架构，统一技术栈，降低开发难度，提升开发效率，增强业务稳态和扩展性。相比此前整个运维团队都忙于稳固MySQL集群，现在大家轻松多了。
- 性能提升与混合分析：解除当前架构中的性能瓶颈，系统性能提升70%，同时支持实时报表查询，减少了数据链路开发与维护的工作，兼备混合分析场景的支持。
- 运维效率提升：数据库平台化管理，支持DBA白屏化操作，提升了运维效率，降低了运维工具开发和运维成本。
数据库迁移经验解析
使用OMS（OceanBase迁移工具）进行数据库迁移方案。原MySQL集群是基于中间件的多实例分库分表集群迁移OceanBase。从迁移策略来说，使用OMS将多条链路分步汇聚到OceanBase。按照读写分离策略，先迁移读业务，后迁移写业务，这样的优点是系统稳定性较高，业务平滑地过渡至新系统。最大化地保障用户体验，让用户对系统变动无感知。
在切割方案中，数科技术团队对读写业务进行应用改造以适配双数据源，设置合理的规则，在整个迁移过程中分批次进行业务迁移，直到迁移完成。
这样做的好处是，可以把整个业务的迁移风险降到最低。第一步只是利用小部分流量做迁移测试，确定没问题后再进行后续步骤逐一迁移读写业务。每步迁移过程在10秒内即可完成业务迁移，对业务影响极低。
在迁移过程中，合库合表是较为棘手的问题，这是MySQL 分库分表集群迁移 OceanBase 必须考虑的问题。不仅需要对每张大表检查验证，确认每条数据的唯一性，并配置合适的大表分区键，确认热点 SQL 的性能最优，还要考虑历史数据能够快速卸载，保证运维清理能够简单高效。
该业务大表主键使用雪花算法，这种算法只能保证每一个DB有唯一性，在多个DB中有极小的概率会存在主键冲突。对于这种问题，如果是小表，可以通过查询、排除主键的方式来更改；如果是几十亿上百亿数据量的大表，使用排除主键法是不可行方案，会耗费大量资源，因此我们对主键做了一些改造，抛弃现有基于雪花算法的主键。新增了自增主键，并对所有DB的自增链设置了一个范围的起始值。这样能够保证在一定时间内数据库的主键不会冲突。而在这个时间段内，需要尽快合库合表并完成迁移。
FLINK生态与OceanBase的结合
debezium格式是万家数科在推进Flink生态所采用的统一，而当时OMS V3版本不支持此格式，如果改造涉及上下游链路非常多预估改造工作量巨大。经过沟通OceanBase-OMS开发团队针对debezium格式进行了相应的开发与适配，保证项目的顺利进行，在此感谢OceanBase技术团队的倾力支持。
基于 BinLog 日志变更使用 kafka-connector 监听对集群数据进行实时捕获。需对每个 MySQL 节点进行日志监听，维护复杂难度大。任务调度不能保证实时性，推送延时大，业务量庞大时存在推送不及时、可靠性较差。
下图基于OMS+Flink调度的流数据实时处理。取代了此前基于MySQL+Kafka的延时较高的任务调度模式。
OMS 提供可视化的集中管控平台，界面化操作，可以基于时间点同步，维护成本低。同时使用 Flink 流实现实时数据处理逻辑。通过 Flink 的 StreamSink 和 TableSink 将处理后的数据实时推送到目标系统。确保目标系统支持实时数据的接收和处理。其 checkpoint 机制，实现任务的持续检查和恢复。在任务运行过程中，定期检查 checkpoint 状态，确保任务在异常情况下能够恢复到一致的状态。
OMS+Flink 方案保证了用户操作简单和数据实时性，整个数据流转可在 2s 内完成，保证每一笔数据消费都能准确实时可靠地推送至每一个用户。
优化案例解析
利用OceanBase丰富的生态体系极大地简化了监控运维的工作，不仅提升了运维管理细粒度，还提高了运维效率。
以OCP和ODC的性能优化为例。
问题出现:
某日凌晨，业务人员反馈在程序发布后，新增业务需求执行效率低下，该场景在UAT环境中性能稳定，上线后效率较之前降低几倍，造成业务单据压单，无法实时处理业务单据。
问题分析:
OCP：通过OCP-SQL诊断功能，发现该时间点TOPSQL中无明显慢SQL，通过与开发沟通得知该场景为高频SQL场景，平均响应时间慢几毫秒均会对业务产生影响，随即确定问题SQL。发现其并无相关索引问题呈现。
ODC：将问题SQL 在ODC执行查询其实际执行计划，定位问题发现SQL存在较多RPC调用
问题解决：
新建表组避免RPC调用。(下图为建立表组后的SQL执行计划基本信息,可见已没有RPC调用)
使用中存在的问题
场景:
业务通过 INSERT INTO ON DUPLICATE KEY UPDATE 避免约束冲突
问题点：
此语法对于约束冲突数据处理方式：
MySQL 日志解析为UPDATE
OceanBase 日志解析为DELETE、INSERT
这对于数据传输下游而言是消费逻辑的转变，这种转变可能会使下游数据存在误差。目前没有找到有效的解决方案，只能尽量避免使用这种SQL语句，用其他语句代替，而这会带来额外的处理步骤。
在 OceanBase 2024年的发布大会中，将带来更多零售行业的应用实践分享，欢迎点击参与！
