请教解决方案 3000个客户端写,另外3000个客户端读 秒级.(新帖)

[chkmouse]

请教解决方案 3000个客户端写,另外3000个客户端读 秒级. （不清楚是否发错了板块，如若错了还请斑竹帮忙，谢谢）


1. 3000个客户端每秒要向服务器提交一次数据，每个客户端每次提交100个字节左右的数据(不算包头)， 服务器存入数据库.
(tcp ip / udp 还不清楚用哪个协议号)

2. 另外3000个客户端每秒要向服务器发送一次请求，服务器根据客户端的标示不同查询数据库，并返回数据.


1. 服务器加队列是不可避免的，但如果向数据库写的时间如果小于每次接收到的数据，那可惨了，队列越来越大，恐怖！
2. 没想好用什么协议，毕竟是3000个客户端，每个客户端每一秒都要一次数据！！！


预计使用独享百兆光纤.

[qq120848369]

select/poll/epoll, 数据库读写压力是瓶颈, 在DB和server之间做cache分担读压力.

写压力可以分摊到一个线程里, 用队列做媒介实现线程间通信, 可以实现异步写入, 减少阻塞带来的延迟响应时间.

如果想综上两点, 就必须考虑数据的实时性问题, 因为写入是异步的, 意味着写入后立即查会失败, 所以应当首先写入cache之后排队等待异步写入DB. 读操作首先查cache, cache找不到再查DB, 做压力测试调整cache生命期, 尽量保证cache失效之前写DB操作可以完成, 大致保证了数据的实时性.

可能简单点的就是mysql做读写分离, 中间加个cache层就行了.

[nice_cxf]

一共6000个连接，估计要有很多路由器，因此最好用tcp协议，100字节的话网络压力大概不算太大，大概6M左右把，管理连接可以用完成端口

[boluomianbao]

最爱的小新
这张好帅！

[Quote=引用 1 楼 qq120848369 的回复:]

select/poll/epoll, 数据库读写压力是瓶颈, 在DB和server之间做cache分担读压力.

写压力可以分摊到一个线程里, 用队列做媒介实现线程间通信, 可以实现异步写入, 减少阻塞带来的延迟响应时间.

如果想综上两点, 就必须考虑数据的实时性问题, 因为写入是异步的, 意味着写入后立即查会失败, 所以应当首先写入cache之后排队等待异步写入DB. 读操作首先查c……
[/Quote]

[qq120848369]

[Quote=引用 1 楼 qq120848369 的回复:]
select/poll/epoll, 数据库读写压力是瓶颈, 在DB和server之间做cache分担读压力.

写压力可以分摊到一个线程里, 用队列做媒介实现线程间通信, 可以实现异步写入, 减少阻塞带来的延迟响应时间.

如果想综上两点, 就必须考虑数据的实时性问题, 因为写入是异步的, 意味着写入后立即查会失败, 所以应当首先写入cache之后排队等待异步写入DB. 读操作首先查ca……
[/Quote]

或者按数据前4字节做int, hash分库也行, 这样的话做线程池并发可以达到更高的性能优化.

[qq120848369]

[Quote=引用 4 楼 qq120848369 的回复:]
引用 1 楼 qq120848369 的回复:
select/poll/epoll, 数据库读写压力是瓶颈, 在DB和server之间做cache分担读压力.

写压力可以分摊到一个线程里, 用队列做媒介实现线程间通信, 可以实现异步写入, 减少阻塞带来的延迟响应时间.

如果想综上两点, 就必须考虑数据的实时性问题, 因为写入是异步的, 意味着写入后立即查会失败, 所以应当首先写入ca……
[/Quote]

是按照数据的名字hash分库, 做上4,5个一样的库, 这样读写压力也能均摊一点

[qq120848369]

是100字节 ? ... 那没什么压力了, 随便写吧.

[qq120848369]

[Quote=引用楼主 chkmouse 的回复:]
请教解决方案 3000个客户端写,另外3000个客户端读 秒级. （不清楚是否发错了板块，如若错了还请斑竹帮忙，谢谢）


1. 3000个客户端每秒要向服务器提交一次数据，每个客户端每次提交100个字节左右的数据(不算包头)， 服务器存入数据库.
(tcp ip / udp 还不清楚用哪个协议号)

2. 另外3000个客户端每秒要向服务器发送一次请求，服务器根据客户端的标示不同查询……
[/Quote]

楼主的考虑是很周全, 但是我给你算算, 每秒要100 * 3000 = 300000B == 300 KB, 连1M都不到, 内存条怎么说也是1G的, 硬盘的读写速率是80+M/秒, 来不及写是不可能的.

其实像这种读写压力都很大的服务器, 就应该是一个线程/进程服务一个客户端, 是apache的架构, 也是mysql自身的架构, 服务端做成master-worker的, 这样不仅是极限使用了mysql的并发能力, 而且对每个客户的响应都是最实时的, 对这种I/O操作慢的程序是很适合的. 配合上一个简单的mysql主从分离读写, 再来个memcache/redis, mysql再分分库, 前边摆上2台服务器, 然后做个L7的负载均衡, 啥压力都没了.

[chkmouse1]

学习学习, 还是楼上的方案比较可靠呀.

[wjb_yd]

没像小新想的那么深入，就用IOCP举例子吧，一共6000个连接。
开几个I/O线程，专门把客户端发送过来的读写请求缓存到一个QuestQueue里面。再开几个work线程，专门从QuestQueue里面提取quest，并执行相关的操作。
细一点思考的，就是不直接从数据库读取，自己设计cache啦。怎么设计MemoryPool啦。注意QuestQueue的同步问题之类的。
不过既然每秒只读写6M的数据，直接用数据库吧。