分布式架构需要注意的地方

1. 业务一定要分楚控制面和数据面。控制面优先级高，需要绝对的可靠。数据面运行频率高，需要绝对的效率。数据面实现业务过程，可以有失败；控制面保证整个业务的正确性，保证数据面失败时业务逻辑仍然是正确的。所以，也许需要分离控制面和数据面的TCP端口、CPU核等。
2. task事务的提交必须要有逻辑Key，即Controller要能识别某个TASK是否已经被处理。防止Client因为失败等原因进行重试，而导致task被重复执行。比如数据库操作，如果不设置key，可能重复写。如果是金融业务，也许就是一大笔钱了。
3. 队列的出入尽量避免多个TCP数据作为写入方，而读只使用1个TCP或少量TCP。虽然理论上一个TCP也能达到NIC的线速，但是因为多TCP连接更能抢占NIC时间片，且健壮性好，且可以与应用层pipeline起来，所以往往会导致队列满的。所以要支持读的TCP个数可配置。
4. 消息的发送过程，要注意单次发送数据量的大小，防止超过队列或某些处理步骤或某些规范的约束，导致发送失败。当然，这种大值有时并不是测试的业务场景能发现。因为测试场景都是比较规整的，而在线的场景往往千奇百怪。所以重要的是自己的代码架构有考虑到。
5. 对网络消息的处理，不管是消息长度还是消息内容都要有容错性。因为网络是不可靠的。
6. 对数据的处理一定要分布到不同的CPU核上；如果是Socket数据触发，则要保证数据收中断均匀上报到各个核上。
7. 并发系统一定要实现业务控制逻辑的完全可并行；同时保证处理对象的解耦。比如存储业务中，对每个BLOCK（比如512KB的数据块）的处理要能够并行处理，同时BLOCK之间完全解耦。
8. 处理过程的不同阶段之间的队列或Buffer，并行度越高，则需要的Size可能更大。比如换大NIC时，由于网速增加，对并行度和Buffer的Size会有更高的要求。