最近项目一上线，就问题颇多，本地测试，ok，上线后，大用户量的时候，顶不住。用了一个礼拜的时间发现的问题，总结下来。
项目是netty4.0，reids2.8,nginx等框架。目前是4台proxy服务器，一台核心服务器，reids只部署在核心服务器上，各代理服务器共享redis数据。
当大量用户访问自己距离较近的proxy服务器时，proxy同时请求核心服务器，并发量到1w时，经常请求卡死，网页请求不回来，开始从netty的http处理并发下手，各种netty的官网，netty的优化，和配置，都修改了，还是没有起作用，后来屏蔽redis后，发现netty处理20w并发一点问题没有，问题确定在redis上。
然后，着手redis的优化，redis的池的优化，配置，没有作用，后台发现，本地访问redis并发1w，很快，但是，访问其他服务器的redis特别卡，发现原因，就在于，跨服务器访问redis，可能由于网络，跨服务器，导致的并发请求redis，回不来的问题，那么，最后，舍弃了proxy服务器远程调用核心服务器reids的方案，nginx改为所有心跳请求，跨过proxy服务器，直接走核心服务器，这样相当于本地访问redis，最后担心核心服务器并发能力，暂时，开启了2个服务，处理所有并发，reids问题得到解决。
总结：就是reids本身性能没有问题，处理并发能力ok，就是跨服务器远程访问其他服务器reids时，并发大了，网络延迟等，会出现取reids卡死。
更高效地提高redis client多线程操作的并发吞吐设计
Redis 2015-05-10 09:51:44 发布
| 您的评价: | 0.0 |
收藏 0收藏
Redis是一个非常高效的基于内存的NOSQL数据库,它提供非常高效的数据读写效能.在实际应用中往往是带宽和CLIENT库读写损耗过高导致无法更好地发挥出Redis更出色的能力.下面结合一些redis本身的特性和一些client操作上的改变来提高整个redis操作的效能.
上图是反映平常操作redis的情况,每个线程都独立的发起相应连接对redis的网络读写.虽然我们可以通过批操作的方式来把当前多个操作合并成一个,但这种方式只能针对当单线程,而多线程相互合并则设计上很少关注.从redis的协议来说其实并没有限制,只是在client库的设计一般没有考虑进去.
如果在多线程操作REDIS的同时如果能够合并网络操作,那意味着可以减少操作网络读写的情况把处理能力提升到最大化.这样Client总体的性能都会有所提升,而REDIS也因表层的网络读取减少而达到更好的利用率.
以上是设计图,原理并不复杂,其实就是把每个请求的操作放到一个队列中,后面开启一个线程来把前面的指令进行一个合并操操作.一个线程在高并发下可以无法更快速地合并起来,可以根据需要进行合理的操作线程应用.
这种设计的效果是否真的比较理想呢,以下是一个简单的测试
public void AnycSet()
{
CodeTimer.Time("beetle.redis asynset", () =>
{
Parallel.For(0, Count, x =>
{
ProtobufKey key = x.ToString();
key.AsynSet(new User() { UserId = x, NickName = "sdffffffffffffffffffffffffffffffffffffffffsdffffffffffffffffffffffffffffffffffffffffbeetlesdffffffffffffffffffffffffffffffffffffffffsdffffffffffffffffffffffffffffffffffffffff" + x });
});
});
}
public void Set()
{
CodeTimer.Time("beetle.redis set", () =>
{
Parallel.For(0, Count, x =>
{
ProtobufKey key = x.ToString();
key.Set(new User() { UserId = x, NickName = "sdffffffffffffffffffffffffffffffffffffffffsdffffffffffffffffffffffffffffffffffffffffbeetlesdffffffffffffffffffffffffffffffffffffffffsdffffffffffffffffffffffffffffffffffffffff" + x });
});
});
} 测试结果如下