我们知道分布式系统是一种横向水平伸缩(Scalable)方案，业务决定架构，
不是所有的业务都能够采取水平伸缩就能解决性能问题的，问题的关键还在于数据之间的关系的强弱。
数据结构是不是表达数据之间的关系的强弱？
请注意结构这个词语，当你看到建筑结构，看到你的房屋结构时，你对结构一词可能有更深入理解，既然是结构了，默认数据之间已经是一种强关系。
结构化数据和非结构化数据才是完整表达数据之间关系的强弱。
也就是说，水平伸缩方案适合非结构化数据，也就是数据之间是弱关系甚至没有关系，这是很容易理解的；但如果数据之间是一种强烈的结构关系，我们称之为聚合，怎么办呢？
有一条计算机原理：聚合必然引发争夺，道理很简单：僧多粥少，坐地铁人多就要抢位置。
对于争夺，传统软件的思路就是用锁，某个时刻只能允许一个用户操作这个资源，其他用户线程必须等待其操作完成，于是互联网并排欢乐奔跑的用户到这里被迫强行停下来，等待，听从指挥，如果允许，将被唤醒进入操作。
这种人为强制性的管理措施显然带来了很差的用户体验，甚至崩溃，同时也是不尊重底层辛苦劳动的CPU。因为线程是CPU私有财产，你不能将之充公后再进行管理分配，活活地折磨CPU。
当前对于争夺比较优雅的解决方案是Reactive编程，也就是事件驱动编程。
对于有着强烈关系的聚合数据，我们必须将其作为整体对象来处理，当发生多个并发用户操作这个整体对象时，我们也不能使用锁来对用户进行限制。
参考Java的NIO的Reactor原理，以及Node.js的原理，我们为每个聚合对象分配一个专门的守护者，所有有关这个资源的操作都交给这个守护者操作，通过一个无锁的队列进行快速排队与守护者进行交接。
通过Reactive编程，我们还可以避免某个资源的操作占据CPU线程太久，只要做完有关资源争夺的那点事情后就赶快另派线程做剩余的事情。这样将串行顺序操作和并行操作能够有机细腻度的完美结合在一起。
那么性能的扩展如何解决呢？不能通过水平扩展，就只能通过垂直扩展，这里的垂直扩展不一定是向上扩展，比如PC换小型机，而是一种向下扩展，通过增加CPU核数来提升聚合数据的并发处理能力。
总之，互联网金融代表一种海量数据高事务高速处理，类似高频交易，与前期12306 或光大事件一样，对于我们从业务数据分析方法，一直到底层组件代码编程实现，都会提出新的挑战，产生颠覆性编程革命。