背景
因疫情影响全国线下实体店经营或关店，导致居民所有买菜需求涌向线上渠道，也让我们生鲜SaaS系统的进入超快速成长期。
在这个期间，我们系统面临了很多挑战，其中仓库分拣中心系统数据响应速度慢，是最为迫切需要解决的一个问题。
当时我们分拣任务数已经大几千万，采用的是读写分离的数据库部署方式，在没有复杂查询的场景下，也可支撑线下业务的运作。
随着租户数每天快速增加，此问题必然会导致严重的生产事故，必须在发生之前将问题给解决。
目标
1、仓库分拣中心至少能支撑未来2年的业务发展规模。
2、高峰期查询分拣任务时间不超过1S，修改分拣任务数据不超过500毫秒。
识别业务特点
生鲜分拣有个最突出的特点，大量公司采取今天下单明早送达的方式，则所有生鲜分拣都集中在凌晨近4个小时内全部完成分拣，在其他时间几乎很少会去关注分拣任务，也很少情况会查询以往的分拣任务数据，具备很明显冷热数据的特点。
在生鲜分拣高峰期时，会频繁修改分拣任务数据，在此期间对分拣任务数据进行缓存的意义不是太大且会增加更高的复杂度来保持缓存与数据库的一致性问题。
识别技术复杂度
在大量数据读改的情况下，需保证好请求速度，则属于高性能优化范畴。
高可用保障在原来架构中已有实现，在以往出现系统不可用的情况下，更多是特殊查询导致仓库分拣服务被拖垮，只要解决掉高性能的问题，也解决当时可能会出现系统不可用的情况。
原有架构分析
仓库分拣中心由多个微服务组成，在部署时每个微服务部署多份，分拣中心数据库采用一主两从的部署方式，一主数据负责写，两从负责读取，是一个典型常见的读写分离的架构模式。
这种方式虽简单，但无法避免数据库单表数据暴涨的情况，只要单个数据链接产生慢查询，会造成一连串的反应。 所以，必须解决单表数据量大的问题，而解决方案则自然是分库分表。
架构改进方案
未来容量评估
经过分析以往数据增长趋势并与业务方沟通预期，通过租户数、用户数、订单数 可以计算出分拣任务数的预期值，也就是说未来3年后保守估计也会超10亿条。
分库分表方案
水平分表普遍可能采用关键Key取模或一致性Hash算法等方案。对于我们业务场景而言，可行但不够实用，还需要考虑以后扩容的方案的实施。
根据分拣业务的特点，我们直接采用了冷热数据分库分表的方式，在热数据库里保存最近15天分拣任务数+未分拣完成的数据。对于冷数据的处理，我们采用的单独数据库按照月份保存冷数据。
冷热数据的“迁移”工作，我们采用的是双写操作，在写入热数据的同时发送消息队列写入冷数据，在分拣非繁忙时间段则开启定时删除功能热数据。
这里刚上线时犯一个错误，虽然热数据对比之前数据量少了很多，但删除操作也会造成锁表，导致程序报错，后面调整为逐步单次少量删除。
分库分表工具的选择
目前主流的以嵌入代码为代表的是sharding-jdbc，而以中间层代理的是MyCat。各种工具各有优劣点，都需要结合团队和业务情况进行选择。
在我们方案里，这两种我们都没采用，最终决定自己实现。考虑点主要有：
1、原来基于多租户的架构，我们已经在MyBatis基础上实现了租户隔离机制，类似分表逻辑。
2、根据时间冷热数据分表操作，在技术上实现并不复杂。
3、随着数据量增加，如按月分表数据量太大时，自研发逻辑也很容易重新进行简单改造。
冷热数据实现简单但需要产品方进行妥协，常规查询需要避免跨月查询，几乎所有常规查询都必须时间。
分库分表搜索查询方案
对数据库表进行分表操作后，原来一些简单的SQL语句使用上有很多限制了，比如gourp、join、count等等。
那么业务场景中一定会存在根据分拣商品名称进行模糊搜索的情况下，那么我们应该如何满足？
不能直接查询数据库，就必然需要引入搜索引擎。因原来此项目的架构定调，如云基础服务能满足我们技术需求节约运维成本的情况下，我们优先考虑云服务，根据了解后我们采用阿里云开放搜索。
使用阿里云开放搜索，定义好相关数据结构映射的工作后，基本上可以进行直接使用了，免去处理数据库同步数据到Elasticsearch这块复杂的工作。
而对于使用阿里云开放搜索有几点建议：
- 技术上是否倾向于云原生的架构。
- 对搜索引擎是否有较多场景的需求，而阿里云开放搜索限制较多，但可以快速满足最基础的搜索诉求。
- 搜索主表数据尽量冗余，阿里云开放搜索是将多表合并为宽表，如单一表(分表后)结构能满足搜索的情况下是最好的。
- 我们使用阿里云开放搜索时是刚推出不久，需要对此抱有一定的容错性，尝试新事物对于业务来说不是核心业务功能。
分库分表常见问题
如何迁移旧数据？
考虑到热冷数据和迁移工作量的原因，我们并没有迁移旧数据，直接当做原来超过15天的数据是冷数据。只是将15天内及未分拣完成的数据，迁移到热表中。
事务问题如何解决？
对于改造前和改造后，在分拣核心事务方面是没有太大区别的。对于双写热冷数据的操作则是通过消息队列事务 和 删除热数据前的校验机制。
总结
遇到技术不满足业务发展要求，我认为是幸运。 当运维反馈请求量太多、数据量太多了，导致系统慢了，这个对于公司而言是好消息，对于技术人而言是更好的消息。
技术是支撑业务发展的，不排除有一些技术是可以引导业务走向的。 但我们大多数技术人都是为了业务而服务，必须清晰决策架构方案，没有完美的架构，只有最适合当时的架构。