大数据量下的条码供应商的系统架构.docVIP

作者：蒋彪 时间1.?????需求 朋友的一家公司，拿到了风投，准备做条码供应商软件。 简单说起来，就是提供整套的条形码技术解决方案给制造业产商。让产品从生产到入库到销售的整个流程通过条形码被我方系统记忆。 产品的简单需求如下： a.???????条码供应系统是SaaS的互联网产品。要求高实时性，高可靠性。 b.??????条形码预先由我方系统生成并且记录。 c.???????客户方购买我方的条形码，并且在生产，制造，销售各个环节将包括该批次使用的条形码数据用XML文件传给我方系统。 d.??????我方系统实时的读入这些XML文件，并且比对我方数据，更新该条码的使用情况，更新该商品的情况 e.??????我方系统对公众提供接口，可以通过购买商品的条形码可以实时的查询该商品的产地，原料，生产日期等等信息。 2.?????现有系统的架构 ? ? ? ? ? 目前最大的性能瓶颈： ????????????????DB是目前最大的性能瓶颈。前端的负载均衡可以上F5，tomcat可以升级成WebLogic，前端的压力总归是可以简单的解决。问题在于后端的数据量上。条形码的数据量高达几十亿，上百亿。同时，厂商又可以实时性的更新数据，在线用户又可以实时性的查询数据。 3.?????我的建议 首先要对DB切分。 3.1??????先根据业务逻辑横切DB 根据厂商 - 商品 - 日期(最好能缩小到天为单位)切分表。 另外根据现有需求，不同厂商之间的数据不存在大范围的同步。所以可以将不同的厂商作成不同的DB服务器，每个厂商数据库考虑建立双备份。 每个DB服务器进去以后先有一个商品ID的hash表做路由，连接到不同的商品表上去。然后再有一个商品- 日期的路由表 (考虑按年份分割开来) - 条形码数据。 3.2??????接下来，我们来将同一表上的查询压力和更新压力分开 我的建议是，在DB前面加上memcached的内存服务器，将常用待查询数据cache入memcached中。虽然不能避免对数据库的查询，但是应该能分担一定的压力。 另外，技术选型上我推荐用mysql。 3.3?稀释厂商实时大批量上传更新数据的压力 厂商会实时性的向我们系统上传大数据量的xml文件。随着产品的成熟，可以想见未来的性能压力。 所以，我建议， a.???????用hadoop分析厂商上传的xml文件。读取当前的xml文件，读入内存中，然后用按照厂商 - 商品 - 日期的规范分割数据，快速定位到所在DB的所在表，执行更新。 b.??????在性能压力巨大的场景下，可以考虑厂商上传xml文件之后不适时性的返回成功与否的标识。稍后用邮件的方式通知客户。这样就能降低厂商的实时性要求。 3.4?我建议的架构模型 ? 4.?????补充 问题基本上解决了。但是还是很笨重。 这个问题的本质是两个大数据量集合的比较和匹配。 这其实是个数学问题，比如用特征码，用算法抽象特征值都能更好的解决。 一个厂商一个DB没有必要吧, 固定数量的DB, 每个DB上加库就可以了, 数据还是按特征散列到某台DB存储.?楼主这个新架构图主要是多了一个memcache层，然后就是DB的垂直拆分， 再就是每个DB做master-slave。master在Hadoop端挖掘入库，再republication到线上slave提供用户服务。缺点就是不应该垂直拆分，而应该按特征字段散列拆分而不是根据厂商拆分（横向拆分），至少淘宝目前也是这样做的，可以无限的扩展，只不过DB坏了会非常影响服务，所以最好每个DB做成双Master，多Slave来消除单点，同时缓解压力，可扩展性也更强。DB改进具体一点讲：每个DB都有3个库，每个库对应一个厂商。根据条形码之类的特征，散列到任意一个DB上，根据其厂商使用对应的库。 Hadoop负责数据挖掘后Master入库（每个DB双MASTER热备），用户端在每个DB下的两个Master分别挂若干Slave同步Master库提供线上服务。好像也没什么难点，前端LVS+KEEPALIVE只是个报警作用吧，这种Web系统更像是一种应用，难点在于业务本身而不再Web本身，所以Web架构层面需要做的不太多，主要需要考虑这么几点：1，Hadoop与Apache的交互，这个属于比较慢的部分，应该考虑前端做1台nginx反向代理，后端挂若干台APP服务器专门负责操作Hadoop，这样可以选择性能较高的APP服务器，另一方面也让Nginx专心搞网络I/O，将来上传数据量持续增大易扩展。 这时候才有必要LVS+KEEPALIVE，做一台备用Nginx。2，用户端主要压力瓶颈在数据库查询上，所以用Memcached毋庸置疑。架构方面已经没有什么讲究了，主要是之前说的每个D