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

作者：蒋彪

时间：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. 补充

问题基本上解决了。但是还是很笨重。

这个问题的本质是两个大数据量集合的比较和匹配。

这其实是个数学问题，比如用特征码，用算法抽象特征值都能更好的解决。