【摘要】
面对高并发账户记录查问问题，依照本文的介绍一步一步操作，就能无效晋升性能。点击理解高并发账户记录查问
问题形容
高并发账户记录查问在银行、互联网企业、通信企业中宽泛存在。例如：网上银行、手机银行、电商个人账户查问、互联网游戏账户等等。这类查问有三个共同点：
1、数据总量十分大。用户数量自身就十分多，再加上多年的账户数据，数据量能够达到几千万甚至上亿条。
2、拜访人数泛滥。几百万甚至上千万人拜访，属于高并发查问。
3、不能让用户期待。手机、网页要达到秒级响应，否则重大影响用户体验。
上面以某银行账户定期明细查问为例，给出这类问题的解决办法。
某银行共一亿个定期账户，每个账户均匀每月有 7 条数据，每年数据总量 84 亿条。每条数据中的机构字段，还要关联分支机构表（几千条）记录。在性能上，要求单台服务器反对一千个以上的查问，响应工夫不能超过 1 秒。
有序行存
定期明细数据随着工夫增长十分快，一年就有 84 亿条。如果放到内存中，须要大量内存空间，硬件投入老本太高，所以要放到硬盘上存储。分支机构表只有几千条数据，能够放在内存中存储。
在硬盘上存储，要思考是行存还是列存。列存数据分块压缩，能缩小遍历数据量。但因为账户查问是随机的，整块读取会有额定解压计算。而且每次取数都针对整个分块，复杂度较高，性能不如行存。因而，这个场景要抉择行存存储，如下图：
图 1：行存和列存
具体的实现能够采纳 Java、C++、SPL 等高级语言。这里咱们以代码量起码的 SPL 语言为例解说。
代码示例 1
A1：连贯生产数据库，用游标读取活期存款数据，依照账户 id 排序。
A2：建设本地组表文件。
A3：建设组表，并从数据库游标读取活期存款明细数据，写入文件。
其中，A3 中的 @r 选项，就是建设行存文件。一年 84 亿条数据都导出，工夫会比拟长。然而这是一次性的工作，后续就只须要追加增量数据即可。增量数据的追加办法，前面会有介绍。如果依照账户排序会对生产数据库造成较大压力，能够导出之后基于文件排序。排序应用 SPL 的 sortx 函数，具体用法参见函数参考。
利用索引
要利用索引提速，先要对明细文件建设索引。因为明细数据量大，建设的索引文件也会很大。很难全副加载到内存中。能够建设多级索引，如下图：
图 2：多级缓存
还是以 SPL 为例，建设多级索引，只须要在“代码示例 1”的根底上，减少一个网格即可：
代码示例 2
A4：对行存文件建设索引文件。
加载的索引级别越多，占用存储空间越大。同时，账户 id 的跨度变小，加载到内存中后，索引成果也会变好。查问时能够依据内存大小，尽可能加载更多级别的索引，能够无效进步查问速度。
在查问之前，零碎初始化或者数据变动时，要事后加载多级索引，以 SPL 代码为例：
代码示例 3
A1：判断全局变量中是否存在 detailR，如果存在，示意曾经加载了索引。
B1：如果全局变量中没有 detailR，那么关上组表加载三级索引。@2 或者 @3 示意加载 2 或者 3 级索引。
B2：detailR 存入全局变量。
这段事后加载的初始化代码（代码示例 3），能够保留成 init.dfx，放入集算器主目录（main path），在节点机（unitServer）启动的时候会主动被调用，如下图：
图 3：节点机主动调用初始化代码
因为咱们提前准备好的定期数据是对账户 id 物理有序的，查问时依据索引找到账户 id 后，能够在硬盘间断读取，显著缩小磁盘 IO，无效提速，如下图：
图 4：索引和有序行存
查问账户 10100，先利用内存中事后加载的多级索引和索引文件，疾速定位到定期明细数据文件中的地位，再间断读取到账户 id 有变动为止。因为数据是依照账户 id 物理有序的，所以文件的其余地位不可能再有 10100 账户的数据了。
利用索引查问的示例代码如下：
代码示例 4
A1：全程变量 detailR 曾经缓存了三级索引，当初能够基于它利用索引，依照条件取出账户为 10100 的记录。
每个账户的数据量并不大，所以能够全副读入内存。
定期明细前端利用（网页或者 APP），要通过集算器的 JDBC 驱动调用 SPL 代码查问。调用的时候，须要将账户 id 作为参数传给 SPL 程序。例如：定义一个网格参数 countid，传入账户 id 为 10100。A1 中的代码就要改为：=detailR.icursor (;ID==countid,index_detailR_id).fetch()。
关联查问
查到指定账户数据装入内存后，能够将机构数据也读入内存。在内存中关联计算，性能能够失去保障。示例代码如下：
代码示例 5
A2：读入机构数据。
A3：账号 10100 的定期明细数据关联机构数据。
A4：将账户 id、分支机构名称和金额返回给前端调用者（网页或者 APP）。
机构数据能够在利用零碎初始化的时候加载入内存，不用每次读取，查问速度更快。在下面提到的 init.dfx 中减少代码如下：
代码示例 6
事后加载机构数据之后，查问代码要在“代码示例 5”的根底上去掉加载机构数据的局部，批改之后的查问代码如下：
代码示例 7
A2：间接用事后加载的全程变量 corp 和定期明细数据关联计算，省去了每次查问加载机构数据的工夫。
数据更新
定期明细贷款是按账号有序的，并不是按日期有序。所以，不能在开端追加当日新增数据。定期明细几十亿条，如果每天有序归并新数据的话，耗时太长。每月归并一次的计划比拟现实。如果将定期明细数据看成是主文件，那么更新原理如下图：
图 5：数据更新
数据更新的示例代码如下：
代码示例 8
A1、B1：如果是每月 1 日，重整文件。
A2：从生产数据库中读入当日数据。
A3：将当日数据有序归并到集算器主动生成的补文件中。