对过去项目的总结--大数据处理篇

       之前总是困惑于大数据、高并发解决方案，感觉总是云里雾里的不知从何把握。最近闲的时候有时候会静下心来对过去做过的项目做一些沉淀，发现其实大数据，高并发的解决方案在那些项目中已经遇到过了。
       众所周知，大数据处理的瓶颈在于数据库。所以从早期的单数据库单实例到后来单数据多实例再到后来数据库集群，都在想法设法提高数据库性能。但是对于几千万线上用户和动辄百万日数据量的应用来说数据库集群也不能根本解决数据库性能的问题。
       对于数据量非常大的应用，我们之前的方案是分表分中心。所谓分中心就是将整个数据库分成几个独立的片部署在不同地域，分表就是再在各个不同中心里对单表拆表，分成几个分表。分中心的意义在于减轻单个数据中心的负载，而分表则在于不仅减轻每台数据库服务器的负载，并且减轻单表的压力。而由此带来的对数据访问的不确定性则通过用户编号或者应用中的某个核心视角来控制。比如一个在线的订购系统，其主视角必然是订单或者用户。则由此对订单和用户的编号的生成采用一定的生成策略。
       比如一个省级的系统，全省12个地市，总共3kw的用户量。则在全省划分4个中心，平均每个中心700-800w的数据量，当然这是比较粗粒度的划分。则中心有1，2，3，4.然后对每个中心分表，每个中心平均断出3张表，假设该表名为quote。则有这样的结构：中心1-quote1,quote2,quote3；中心2-quote4,quote5,quote6；中心3-quote7,quote8,quote9；中心4-quote10,quote11,quote12。然后对每个地市进来的订单按照地市编号生成订单及用户id。假设该省的区号是0571-0583。如果数据由0571地市进来，则生成的id需是这样的结构571*********后面取多少位视实际应用规模而定。这是对于存储而言。
      而对于访问而言，则以用户为视角，基于用户的Id就能知道用户对应的数据在哪个中心的哪个库。比如一个571123456789的用户必然应该路由到中心1的quote1上去。
      而在实现细节层面来说，要做的则是proxy被请求的service。首先根据区域编号或者用户编号（可配，视业务需要）路由到具体的中心。再在ORM层对所有的sql表名拼上分表。再执行，则这样就能路由到正确的数据源上的正确表了。