交易并行度设计

yulihua49

初次架构并行交易系统的朋友们，往往注重并行度，异步化这些问题。
但是，事情并非是越并行，越异步越好。
先说并行度的问题：
在一个分布式交易系统中，有好多环节分布在不同的服务器上，每个环节会产生每个环节的瓶颈。但是，整个系统必然有一个主瓶颈。最常见的主瓶颈是数据库，有时也可能是网络带宽。
对于数据库来说，有一个最佳并行度，它不是一个值，而是一个范围，在这个范围之外效率会降低。其他环节的并行度，受限于这个并行度，过高的并行度并无好处。
再说异步操作问题：
并非是异步操作比同步操作高效，相反，异步操作通常效率较低（这里所说的异步，并不单纯指异步IO，有些业务处理也可以异步的）。那么我们为什么要考虑异步操作呢？为了并行操作服务。
异步操作是为了腾出CPU进行其他任务，也就是并行辅助手段。并行和异步都是有开销的,有时开销还很大。
如果一个大的作业被划分成小的并行单元，这个单元过小，为他付出并行和异步开销是否合算？

所以，并行架构设计要注意三个适度：

适度并行。

适度异步。

适度粒度（批量）.

对于OLAP（在线分析处理，通常是在线交易分析），对于大批量的数据源，通常是需要拆分成小的并行单元。他的处理环节也比较多，哪里设计并行，哪里需要异步，批次大小的选择，有时就需要一个或几个demo系统，综合评价一下。
而OLTP（在线交易处理），通常处理的颗粒度很小，往往需要合并。一个用户不太容易与另外的用户合并。应该是把自己的各个步骤合并，而不是拆分。典型的，例如12306那样的交易系统，可以把：到发站车次查询，时刻表查询，票价查询，席位余额查询合并。事实上也是这么做的。

hellioncu

说了跟没说一样

windoze

回复 1# yulihua49

加点细节吧，有实例最好。
然后就可以入选精华了

cokeboL

新产品的话，宁愿golang从头，大多数情况都是顺序编程

yulihua49

yulihua49 发表于 2015-08-17 11:21
初次架构并行交易系统的朋友们，往往注重并行度，异步化这些问题。
但是，事情并非是越并行，越异步越好。 ...

这是在一个OLAP项目中有感，设计者做了一个处处异步，点点并行的方案，粒度划分的非常小。
有一个普遍的意识，似乎异步处理性能要高于同步处理。

我的想法是在拆分(map-reduce的主map点）的主节点上提供有限的异步就可以了。
比如后台有8个并行度，主分发节点map异步发出16个包，其中8个被处理，8个在等待。然后就不必继续map了，等一下，处理掉多少再map多少。尽量减少处于未完成状态的交易数量。（设计者的观点，数据全部抓过来，处理不了的都放在内存队列，好巨大啊，都是未完成态，然后是事务完整性管理。。。哪些做好了，哪些失败了，需要commit？rollback？redo？abort？。处处异步，无限度的异步。）
其余节点都是同步处理，这样容易保证交易完整性。

还有粒度，小到一个处理只需几十微秒，为他开销了好几个毫秒的异步和并行。

yulihua49

cokeboL 发表于 2015-08-17 13:40
新产品的话，宁愿golang从头，大多数情况都是顺序编程

一个旧系统改造项目，重新架构。原系统是顺序的串行系统，单节点操作。新系统是多节点并行操作，一个是要性能，二是要容错，不能有单点故障。语言不是问题，关键是架构，这也看出架构对系统的重要性。
每天要分析4400万交易，逻辑还是相当的复杂。

fender0107401

Good！

fender0107401

虽然我的系统也要处理打量的数据，不过逻辑什么的还是相对简单的。

cokeboL

回复 6# yulihua49


    如果用go的话，可能就不存在这几个问题了

yulihua49

fender0107401 发表于 2015-08-17 15:07
虽然我的系统也要处理打量的数据，不过逻辑什么的还是相对简单的。

如果逻辑简单，也没什么性能、容错方面的要求，当然架构就简单些，谁也不愿意找麻烦。
但是你的业务发展了，有新的要求，架构问题就提到桌面。
新接触并行处理的架构师们，需要一个合理的逻辑，或者叫理念，去设计他的系统。