搜索引擎|分布式系统中数据存储方案实践( 二 ) 中间件

通常来说由控制中心进行统一的管理和维护应用库的配置数据，在各自的应用服务中直接查询即可；从而避免重复实现各种基础功能，同时将系统级的管理都放在控制中心服务，确保数据修改的入口单一，以便更好地监控动作日志；
四、业务数据作为系统最核心的数据资产，业务数据的精准维护一直都是核心事项，除了提供必要业务流程的数据存储，还要支持数据的动态查询分析，并且会随着业务发展，数据的结构和体量也会不断产生变化；

分库分表：业务过度复杂的时候，会考虑库的拆分，从而保证各个业务块的相对稳定性；当某些表的数据量庞大时，会采用分表的方式，避免该表的处理时间过长从而影响整体性能；业务的库表拆分并且基于微服务管理，是当下主流的架构模式；

数据维护：随着业务的发展，数据体量和结构会随之膨胀，从而引发质量问题，所以在日常开发中很多版本都会进行数据维护，比如：数据清洗、数据迁移、结构拆分等，从而更好的管理数据保证业务的持续性；

微服务架构下数据的动态维护是一个比较复杂的流程，要保证在处理过程中不停机，需要依赖中间的调度服务去完成数据的维护过程，在此期间应用服务优先从旧服务和库中读取未处理的数据，新数据入库和查询走新的服务，直到整个维护流程结束，再根据预设好的标识关闭旧服务请求并且下线即可；
五、缓存管理通常缓存可以有效解决数据查询时出现的性能问题，比如访问量大变动不频繁的热点数据，或者流程中经常加载的常量配置，另外也会基于Redis做加锁机制，一般采用键值对的方式管理数据读写；

值得注意的是，通常Redis库与业务库是具有一定的对应关系，例如订单业务库对应订单缓存库，并且不建议订单业务库数据主体被写入其他缓存中，统一通过订单服务的接口访问即可，保证各个微服务的数据独立性；
六、搜索引擎当业务量大的时候，很难执行数据整体的条件检索机制，比如常见的核心业务数据、系统产生的日志或者动作埋点数据；需要引入搜索引擎的能力，这就涉及到业务库数据向ElasticSearch组件同步的过程；

不同的业务场景中，通常采用不同的数据同步策略；针对即时性高的业务数据，通常数据入库后执行写入；日志数据量大且流程解耦较高，自然存在一定的延时；分析类的数据则基于定时任务拉取即可；不管什么数据路径，都要重点关注业务库和索引之间的数据结构和一致性问题；
七、消息队列消息队列作为流程解耦的常用组件，对消息数据的生产和消费需要一定的监控手段，复杂的流程一旦中断，需要进行二次重试的话，则需要调度各种参数和消息内容结构，来保证流程的最终完整性；

通常来说消息队列处理的业务复杂性都很高，所以比较考验流程设计的合理性，如果不统一管理消息的生产和消费的路径，在微服务的架构下基于MQ做流程的分段解耦，如果出现流程中断或者系统异常的情况，都很难对相关逻辑做二次调度；
八、日志信息日志作为系统中的基础组件，记录的相关数据在日常开发维护的过程中十分重要，从数据的整体来看大致分为系统运行日志，通常基于ELK的方式，另外就是业务日志，需要具备业务语义，通常采用AOP切面模式进行定制开发；

由于日志数据的体量很大，业务日志一般会存放在单独的库内，并且同步到搜索引擎中，对于系统运行日志则按照时段或者文件大小的策略直接写入搜索引擎；值得注意的是存放日志数据的ES也需要独立部署，避免与核心的业务数据放在一起，当流量突然增长时产生的日志数据会非常大；