大数据量下的条码供应商的系统架构
作者：蒋彪
时间：20120419
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. 补充
问题基本上解决了。但是还是很笨重。
这个问题的本质是两个大数据量集合的比较和匹配。
这其实是个数学问题，比如用特征码，用算法抽象特征值都能更好的解决。