接了一个公安局的银行流水分析的活儿,需要将从几家银行调回来的N多帐户的流水,汇总为一张表,进行多种维度的分析.因为之前一直做的ERP,系统复杂度主要是各部门 也就是各子系统 也就是N多表之间的关联,单表复杂度远不及此,所以出现了些新的问题:
    举个栗子:每笔流水都记录了登录IP和MAC,需要统计哪些帐户在同个IP或MAC上登录过,记录为一个层级,仅这个就需要建立IP,MAC及IP+MAC三个索引,然后以每个帐户为基础,进行一遍一遍的索引扫描,先找这个帐户所有的IP,然后找这些IP所有的帐户,再找这些帐户所有的IP,直到找不到新的IP或MAC或新的帐户,造成完整计算一次耗时数十分钟,好在数据的增加并不是实时的,隔一段时间才会有新的数据添加.所以通过构建结果缓存表的方式,处理了这个问题,每次增加数据后,重新计算并填充结果表就OK了.
    类似的需求还有不少, 所以造成建立了数个结果表,回头看看,系统虽然暂时能应付,但是原始大表上建立了8个索引,这些索引都只是偶尔使用的,造成空间比较大的浪费也影响了性能,每次导入资料完后,需要进行的计算多达十多步,明显即不智能也不优雅,而且关键是如果需要实时的数据添加,怎么处理这问题呢?
    考虑很久...,其实问题虽然复杂,但是本质上看与最简单的帐本应用也没什么区别,帐本应用需要录入一条流水,然后计算余额,系统需要录入一条流水,然后执行N个计算,复杂的只在于帐本只需要维护一个余额即可,本系统却需计算N个结果,以便产生不同维度的报表,既然如此,可索性分解为不同的子系统,例如:计算层级需要按IP 按MAC 按IP或MAC 按IP和MAC进行四种统计,即分解为4个独立的子系统 分别维护4个结果,录入一条流水后,4个子系统自动分别计算(这里应该可以通过一些优化不用清空重新计算)
    再想想,其实所有的系统本质上都是输入->计算->输出,如果一个系统将所有的输入全部以日志的形式记录下来,会有什么好处:
    1.系统可以随时重建,随时全部或部分的回到过去的任何一个时点(例:员工误操作删除了几个客户的交易记录 可仅还原那几个客户的资料不影响其它数据)
    2.任何大问题均可分解为小问题,大功能分解为若干子功能(每个子功能只需处理日志队列即可最终一致)降低复杂度就是降低出错率 及提高优化可能性(用最新技术重写一个帐本应用很简单 重写一个使用中的ERP基本不可能)
    3.为了防灾多个相同数据源:不论数据源个数都可以作主数据源,仅需同步日志 即可保证多个相同数据源的最终一致,通过数据代理层的一些策略,可以最大限度避免脏数据可能,并能显著提高系统处理能力和防攻击能力
    4. 分布式数据源:其实分库分表本身就是大问题分解为小问题的思路,1个数据源只处理用户名开头为A的数据,另个数据源处理开头为B的...通过数据代理层的调度,无数的大流量将分解为小流量,大数据将分解为小数据,理论上系统处理数据的能力将没有上限.
...说不定还有没想到的 不过有这几个就够了 

    顺便点评下:
   .12306的难题就在于分解到每趟列车就不能再往下分解了 分解为每趟列车售票而言面对的人也是海量 其实提前半年售票问题就解决了 还可以赚几个月利息 也方便根据数据安排加班列车 大不了价格有浮动多退少补也不会有怨言
   .淘宝的双11却可以分解到每家店下的每个商品 一个商品面对的客户不会有春节同时买一趟列车票的人多 支付宝也可以分解到每个人 一个人每秒付款次数基本忽略不计...
   .所以银行页面很卡是没道理的 多的是钱
   .电信也是...最垃圾就是电信,带宽都不要成本,连个首页都显示不全,还有脸通过DNS拦截在用户电脑上瞎弹广告 短信不要成本 价格却比不上任何一家代理或虚拟运营商 连效果也比不上 电信要是私营 根本没BAT什么事儿 以本伤人一招鲜
   .无竞争无服务 

浅谈以[日志]为基础构建系统的原理和优势