互联网对账结账问题预热

   我觉得这是一件很有学问的事，然而这个学问我并没有。不过我们可以一起学习，这篇文章我将会以 分享我淘到的帖子的方式和大家一起学习。另外我会提出我遇到的问题，我都列出来，我们一起寻找解决方案。如果项目能够上线，我也愿意分享我最终的解决方案。

# # 展望

  为什么说这是一件有学问的事。对一个公司来说，账不平，都是自己承担的，百花花的银子，能没有学问吗？

  不想卖高价的猪就不是一个好猪。我们在设计系统的时候，永远要站在架构的角度，拿着望远镜看的眼光才行。比方说我在做的对账系统，虽然是在初期，不太会有太多的用户进来，不太会有太多的订单量，明明连上完的订单量都没有，但是我们却要考虑千万级别的设计。需求往往就是这样，不然做技术的哪儿来的好玩。

# # 问题清单

  1. 千万级别，我们应该选用哪些技术，用什么技术架构号一点。

  2. 读数据分页的问题。别说千万级别了，就是十万级别的数据，都是一个问题。

  3. 处理数据 OOM 的问题。

  4. 对账流程应该怎么写？如何保证一个全覆盖的对账。

​

# # 我自己的不现实的想法

 1. 情况是这样的，我的需求只有对两张表的的某个字段，就是订单号。 A表出现了，看B表出现没，如果没出现就记异常，反之亦然。如果没有都出现了，则需要对比出现的次数。看出现的次数时候一致。因为只有一个字段，varchar 10 ，我想的是，都查出来以后放在 set 中去。具体想法我贴一个手写的图：

   为什么说不现实呢，从数据库一下子取这么多数据，不合适。 都放在内存中不合适。

   目前的业务量没有那么大，我把从A表B 表取出来的一个字段分别放在 两个 HashMap 中去，我计算的占用的内存，大概占用了1.5 个G。 这让我觉得一下子去处理可行，因为减少了很多的麻烦。

  推荐的处理方案是分页去处理。这里我今天先不写。最终敲定再说。

# # 我的感悟

  站在架构的角度上，从数据库的设计上就应该去考虑这件事。

  另外，对账不是一件小事，我觉得应该专门的去设计一下，架构一下，去应对各个维度的对账。