专场6.1-海量异构数据在线业务存储架构演进与实践-沈剑（脱敏版）.pdf

1、海量异构数据，在线业务存储架构演进与实践KG沈剑关于-我“架构师之路”作者，深夜写写技术文章ex百度-高级工程师ex58同城-高级架构师，技术委员会主席，技术学院优秀讲师快狗打车(原58速运)CTO订单各自为战，存在什么问题？订单数据仓库如何统一建设？订单业务对账，风控如何统一处理？大数据量、高并发量、高可用、订单技术体系如何统一建设？举例：-用户订单列表如何实现？-沟通关闭JOB如何实现？-默认好评JOB如何实现？方案一：继续折腾订单列表？沟通关闭JOB？默认好评JOB？方案二：收归一统订单列表-统一拉取沟通关闭JOB-统一实施默认好评JOB-统一实施数据仓库统一风控对账统一大数据量、高并发

2、量、高可用、技术体系统一数据收口快速实现业务需求-订单列表-沟通关闭JOB-默认好评JOB数据收口-数据仓库统一-风控对账统一原系统不变小插曲，APP侧并发量增大为了提升读性能，单独加了缓存微服务大忌绕过服务直接读写数据库-业务DTS直接写服务后端数据库-业务JOB直接写服务后端数据库无法添加缓存，屏蔽底层复杂性-业务替服务加缓存，复杂性透传-服务本身无法加缓存，读写不收口当读写收口到订单中心服务后订单中心收口完成职责集中-提供统一读写RPC接口-提供统一状态变化MQ通知复杂性屏蔽-屏蔽存储引擎细节-屏蔽cache接下来，数据量膨胀了（读量增加用cache，数据量增加怎么办？）订单中心典型业务

3、场景点查询（90%流量）-order_id(oid)查实体列表查询（9%+流量）-user_id(uid)查oid_list，8%+流量-driver_id(did)查oid_list，1%+流量其他查询（1%-流量）-后台状态，金额，城市，备注，时间等各种属性-group by,offset limit,sum/avg等各种需求常见玩法，订单中心用订单ID水平切分点查询（90%流量）-order_id(oid)查实体列表查询（9%+流量）-user_id(uid)查oid_list，8%+流量-driver_id(did)查oid_list，1%+流量其他查询（1%-流量）-后台状态，金额，

4、城市，备注，时间等各种属性-group by,offset limit,sum/avg等各种需求实践一，基因法，用户ID切分点查询（90%流量）-order_id(oid)查实体列表查询（9%+流量）-user_id(uid)查oid_list，8%+流量-driver_id(did)查oid_list，1%+流量其他查询（1%-流量）-后台状态，金额，城市，备注，时间等各种属性-group by,offset limit,sum/avg等各种需求实践二，数据冗余点查询（90%流量）-order_id(oid)查实体列表查询（9%+流量）-user_id(uid)查oid_list，8%+流量

5、-driver_id(did)查oid_list，1%+流量其他查询（1%-流量）-后台状态，金额，城市，备注，时间等各种属性-group by,offset limit,sum/avg等各种需求实践三，前台与后台分离后台查询（1%-流量）前台访问，后台访问场景差异-访问模式-访问量-时延敏感性-可用性要求-一致性要求资源解耦总结早期业务快速迭代，订单库，分中长期看，订单中心，合-数据建设，数仓统一-风控对账，业务统一-大数据量、高并发量、高可用、技术体系统一从分到合，重在平滑-数据收口，原系统不变-服务收口，原系统蚂蚁搬家迁移微服务分层，两点原则-任何上游不得绕过服务读写数据库-微服务对上游屏蔽存储引擎，分库分表，缓存等复杂性三点实践-水平切分，基因法，点查+列表查询均一步到位-数据冗余，Mapping表解决多维度列表查询-前台与后台分离，解耦，不同技术方案解决不同业务场景Q&A谢谢！