京东资深架构师：高性能高并发服务的瓶颈及突破思路(4)

4、小结

其实并没有一刀切的万能法则,大体原则是根据实际情况具体问题具体分析,找到服务瓶颈,资源不够加资源,尽可能降低每次访问的资源消耗,整体服务每个环节尽量做到可以水平扩展,同时尽量提高单机的有效利用率,从而确保在扛住整个服务的同时尽量降低资源消耗成本.

Q1：在用NIO多线程下,涉及到线程间的数据,怎么交互比较好呢?

A1：在NIO的情况下,一般是避免使用多线程,其实NIO本质上和C/C++里使用epoll效果是类似的,所以像nginx/redis里并不存在多线程的情况(内部实现的时候一些特殊情况除外).

但是如果确实是有NIO触发以后需要将连接丢给线程池去处理的情况,比如涉及到耗时操作,同时确实涉及到临界资源,那只能建议不要让NIO所在的线程去访问这个临界资源,否则整个NIO卡住整个服务就卡住了.尽量避免NIO所在线程出现有锁等待等任何可能阻塞的情况.

Q2：请问老师MySQL也是采用epoll机制吗?

A2：MySQL连接池版参考mariadb的实现其实也有用到epoll这种机制,但是跟我们通常理解基于事件驱动的方式不太一样,我们一般会将其归类为每连接每线程/线程池的方式,相当于将连接最后还是要分配丢给某个线程去处理,而且这个访问操作本身可能是比较耗时的,会在较长一段时间内一直占用这个线程,并发主要是靠多个线程之间的调度达到并发效果.

Q3：Redis、MySQL数据强一致性方案能稍微讲讲吗?

A3：这个还得看具体业务场景,理论上没有特别完美能保证严格一致的,但是在实际情况下可以灵活处理.比如我之前提到的,像商品价格,如果访问量足够大,大到缓存失效打到数据库时直接可以将数据库打趴下,那也可以特殊情况特殊对待,直接让访问打到缓存为止.缓存挂了,访问直接失败,直到重新将数据加载进去.

还有一些情况是频繁的写操作,但写的内容未必那么重要的,可以接受丢失,但是写操作非常频繁,那么可以将写先写到缓存直接返回成功,后续再慢慢将数据同步到数据库.

来源：DBAplus社群

（编辑：ASP站长网）