非一般场景下数据库无缝扩容

特殊场景下数据库无缝扩容

?????? 去年做了一个优化类项目，当时接收时，基本上oracle-db io已经被这个应用占据了79%的load，随着业务发展，DB响应已经到了无法忍受的地步。

?????? 具体场景为：实时监听买卖订单消息，订单保存45天，这些订单会每条都更加用户维度进行分析，分析规则比较复杂，基本有单笔订单，该用户近45天订单全量分析，分析完后给出该订单是否为真假，如果真的订单并且未结束，再汇总出总金额，需要实时计算。

????? 当时高峰期每秒进来订单量在300多，总计每天订单增长数维持在1KW，45天大体订单在4.5个亿。

????? 当时查询性能基本上已经慢到一个用户如果订单量>1000基本上响应时间在5秒以上。后续又来的业务需求，订单状态会发生变化，用户订单也时刻在发生变化，那么我们需要的金额就会时刻在变化，一旦变化就力度非常大，就需要预警。

????? 怎么办？a.新需求

????????????????? b.每天访问量越来越大，性能。

????????????????? c.公司搞大型活动订单高峰期预计比平时高5倍。

?????

????? 拆库是必然的，而且业务发展非常快，至少预估3年可扩展。

????? 拆库成本很高，数据迁移，停机。。。。

????? 半年后如果再次性能存在问题，再搞一次拆库实在不方便，而且还需要评估一些公司大型活动的冲击。

能否有种可以支持半年然后，可以无缝扩容一次，1年后再扩容一次。。。。

?

???假设A用户根据规则计算得出其Key=257,
??? 当用户A有数据进行存储时，
??? 根据映射关系（读写模式为WR）找到对应的数据库实例为Instance2，新增数据将存储到Instance2数据库;
??? 当用户A有数据需要修改或者查询时，根据映射关系（模式为WR,R）找到对应的数据库实例为Instance2，（如果有多个映射关系，循环各个映射关系），查询或者修改对应的数据库。

通过简单修改路由映射关系，解决了传统的扩容情况造成的各种问题。