没有redis也能够支撑小米在印度把亚马逊搞挂了事件的秒杀解决方案

编程入门行业动态更新时间:2024-10-25 18:34:15

没有redis也能够支撑小米在印度把<a href=https://www.elefans.com/category/jswz/34/1769528.html style= 亚马逊搞挂了事件的秒杀解决方案"/>

没有redis也能够支撑小米在印度把亚马逊搞挂了事件的秒杀解决方案

转载地址：

性能表现

ps：jdbc的优化值得参考以及架构思路，故转载作为记录

先说一下性能表现吧，因为大家对这个比较感兴趣。

硬件环境(Tomcat、Artemis、Jmeter、Oracle，backend都在这台电脑上)：

MacBook Pro (Retina, 15-inch, Mid 2014)
2.2 GHz Intel Core i7
16 GB 1600 MHz DDR3
512G SSD

软件环境：

java version "1.8.0_131"
Artemis 1.5.4
Oracle XE 11g (Docker)
Tomcat 8.5.14 (1个)

架构说明

从部署拓扑上看，架构分为4个部分：

webapp，可集群部署，运行在Tomcat中
ActiveMQ Artemis，负责webapp和backend之间的通信
backend，只能单个部署，独立运行，内部使用Disruptor
Oracle数据库

ActiveMQ Artemis

ActiveMQ Artemis是JBoss把HornetQ捐赠到Apache基金会后改名的项目，目前是ActiveMQ下的子项目。

HornetQ是当年大名鼎鼎的高性能消息中间件，因此ActiveMQ Artemis也具备相当的性能表现。

本项目利用它做webapp和backend之间的消息通信。

Disruptor

Disruptor是LMAX公司开源的高性能内存队列。Disruptor能够让开发人员只需写单线程代码，就能够获得非常强悍的性能表现，同时避免了写并发编程的难度和坑。其本质思想在于多线程未必比单线程跑的快。

backend利用它把从ActiveMQ Artemis获得请求串行化，判断商品库存是否充足，更新剩余库存，最后异步写入数据库。

使用内存、避免IO

本项目对于库存是否充足的判断既不在数据库层面，也没有利用redis，更不涉及任何IO。

backend程序在启动时将数据库中的库存数据加载到内存中，库存充足判断、更新剩余库存的动作都是在内存中进行的，配合Disruptor绕过了并发编程的内存可见性、同步、锁等问题，性能非常强。

也许有人会说，在实际项目中把商品信息都放到内存中不现实，怕会发生OOM，其实这个要看具体情况。

在本项目中商品在内存中相关类是Item.java，在利用jol-cli(点此下载)查看其memory-layout后发现，其大小为24byte：

me.chanjar.jms.server.memdb.Item object internals:OFFSET  SIZE  TYPE DESCRIPTION                    VALUE0    12       (object header)                N/A12     4   int Item.amount                    N/A16     4  Long Item.id                        N/A20     4       (loss due to the next object alignment)
Instance size: 24 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

而Long占用的内存也为24b：

java.lang.Long object internals:OFFSET  SIZE  TYPE DESCRIPTION                    VALUE0    12       (object header)                N/A12     4       (alignment/padding gap)        N/A16     8  long Long.value                     N/A
Instance size: 24 bytes
Space losses: 4 bytes internal + 0 bytes external = 4 bytes total

假设你有100W商品需要秒杀，那么其占用内存 = 1,000,000 * (24b + 4b + 24b) = 52,000,000b = 49m。仅仅只占49m。

优化项

架构上的优化点

下单请求异步处理，请求返回的本次请求的ID，客户端拿这个ID到另行发起请求查询结果
在秒杀期间，商品库存信息在内存中，库存判断及库存扣减都在内存中进行，之后异步到数据库
利用Disruptor将并发请求串行化，同时避免了多线程编程复杂度
抛弃数据库事务，采用最终一致性

和JMS相关的优化点

重用JMS Connection、Session、MessageProducer、MessageConsumer，而不是每次都创建这些对象(Spring的JmsTemplate就是这么干的)
将JMS Session设定为transacted=false, AUTO_ACKNOWLEDGE
发送JMS消息时DeliveryMode=NON_PERSISTENT
关闭Artemis的重发、消息持久机制

和JDBC相关的优化点