给绿皮车换上高铁发动机
火车票订单中心重构
web订单系统,对我们来说,都不是一个陌生的东西。然而,高并发从技术的角度来说,这对于Web系统是一个巨大的考验。当一个Web系统,在一秒钟内收到数以万计甚至更多请求时,系统的优化和稳定至关重要。
一、高并发的挑战:一定要“快”
在最短的时间里返回用户的请求结果。
建议采用异步写入。 这就是采用“滞后反馈”,就是说当下不用及时处理的事情,一段时间后才需要执行。
过期请求直接丢掉。某个业务请求接口出现问题,响应时间极慢,将整个Web请求响应时间拉得很长,逐渐将Web服务器的可用连接数占满,其他正常的业务请求,无连接进程可用。
更可怕的问题是,客户端频繁请求,恶性循环最终导致“雪崩”(其中一台Web机器挂了,导致流量分散到其他正常工作的机器上,再导致正常的机器也挂,然后恶性循环),将整个Web系统拖垮。
二、大系统小做
大系统小做应该怎么做?最简单的说法就是面向对象的思想,不断分层分解,形成各种子零件。系统分解成模块,模块分解成服务。
使用大系统小做,分而治之的思想,整个系统可以做到层次分明,清晰有序,职责分明,每一个模块都很简单极致,发挥最大的效能,可扩展可维护可控制。
三、减少数据库压力
1. 尽可能请求不到数据库
如果请求能在服务层就能得到结果,我们就不要去麻烦数据库,如果能麻烦一次就不要麻烦多次,如果能麻烦一秒就不要麻烦两秒。因为数据库永远都是系统中一个性能瓶颈,过多的压力和资源占用,将导致所有请求都卡死。例如能从缓存读的数据就不要去数据库了,可能在一定程度上有脏数据,只要不影响逻辑也问题不大。尽量在数据库上不要做太多操作,占用连接,快速读写数据,运算在程序当中来做。
2. 将数据库分散
分散数据库的压力有多种方式,物理分库,逻辑分库,分表以及分区等等。这种方式只能在一定程度增加数据库的资源,避免资源不够用。
3. 去事务去join
事务将会锁掉很多资源,join将会占用很多数据库运算,从系统逻辑上去解决上面的两个事情,程序可以方便平行扩展,成本相对数据库扩展低很多。