估计很快就会被列入标题党了。入正题了，项目说明：一个基于TCP/IP的通讯程序(可以理解为变种QQ)，C端负责发送订单(单客户端数据量60条/分，客户端数量预计上万，因为是全国范围)，S端接收后，先存，再处理，再分发给其它在线C端。S端异步+线程进行监测连接和数据包到达；
C与S的连接目前是一个端口，考虑到粘包情况，S端独立线程收包，随后独立线程判断包的完整性，再提交给处理线程进行处理(判断完整性和处理用了数据同步)，再接着提交给分发线程(负责入库和分发)。附加说明：数据在内存的存储用了hashtable。每个订单的数据大概是200-300个汉字。程序运行于外网。
问题：就目前这种情况，这种方案有什么可优化的。或是有什么好的方案。望坛友讨论一下。
C与S的连接目前是一个端口，考虑到粘包情况，S端独立线程收包，随后独立线程判断包的完整性，再提交给处理线程进行处理(判断完整性和处理用了数据同步)，再接着提交给分发线程(负责入库和分发)。附加说明：数据在内存的存储用了hashtable。每个订单的数据大概是200-300个汉字。程序运行于外网。
问题：就目前这种情况，这种方案有什么可优化的。或是有什么好的方案。望坛友讨论一下。
每秒峰值多少个包呢？
几台服务器？
hashtable换成Queue是不是好点呢?
有什么好的建议吗？
用SocketAsyncEventArgs一组线程收包,直接扔到组包缓存队列
一组线程组包,直接扔到回调缓存队列
一条线程回调返回给上层最后
你的客户端数不是很多
命令包数也不多
服务器没压力
数据库会不会是瓶颈呢?
如果需要删改，单机数据库肯定受不了。
就算只增加数据，也只能批量写入，单机硬盘受不了每秒几万次的读写。那么处理数据网络流量接近10M/s，这个没问题，但是下面的问题大了。其他在线C端如果预计上万，那么网络流量10000*10M/s=100G/s。
需要确认这数据一定要分发吗？还是让C端自己根据需要来取数据？
如果一定要分发，就需要使用P2P技术，让在线C端相互发数据。
漏看这个功能了:
数据是必须即时转发还是可以适当延时?
每次都要转发所有在线用户还是只转给该用户的好友?
如果我来做
我可能不会使用服务端转发,也不会使用P2P
服务端转发会让服务端更加繁忙
P2P会增加开发的难度,而且P2P环境各异,P2P失败率不低啊
我的做法:
各客户端增加一个心跳命令,心跳时隔可以适当延长
如果需要更新数据,就在心跳包里返回给客户端
客户端主动去服务端更新数据
这样做还有一个好处,可以在服务端控制同时更新的客户端数据
例如,每次只能100个客户端同时更新
处理完这100个客户端,才进行下一轮
数据库有瓶颈目前不是问题。因为这个数据量如你所说， 不太大，主要体现在C与S的实时通讯。交互方面。S端是统一操作数据库，只会延时，或是批量入库。
请教一个问题：
1. “如果需要更新数据,就在心跳包里返回给客户端
客户端主动去服务端更新数据”。意思是返回给客户端的心跳包里含有“是否更新”命令，客户端接收到含有“更新”的命令返回值后，主动发送请求更新客户端的数据到服务器？2. 客户端采用你之前说的“用SocketAsyncEventArgs一组线程收包,直接扔到组包缓存队列
一组线程组包,直接扔到回调缓存队列
一条线程回调返回给上层
”方式更新到服务器上？
意思是返回给客户端的心跳包里含有“是否更新”命令，客户端接收到含有“更新”的命令返回值后，主动发送请求更新客户端的数据到服务器？至于交互的协议你可以自己定。
不过后面你理解反了，是C与S有心跳机制，S是被动下发，C是主要去要。当然上面还有人提到，可以采用分批处理客户端的主要申请