在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
开源软件名称:artemis-disruptor-miaosha开源软件地址:https://gitee.com/chanjarster/artemis-disruptor-miaosha开源软件介绍:artemis-disruptor-miaosha没有redis也能够支撑"小米在印度把亚马逊搞挂了"事件的秒杀解决方案。
性能表现先说一下性能表现吧,因为大家对这个比较感兴趣。 硬件环境(Tomcat、Artemis、Jmeter、Oracle,backend都在这台电脑上):
软件环境:
相关配置见如何准备环境 测试Jmeter脚本见如何Benchmark:
一共Benchmark了两次,因为JIT的关系,第二次的性能表现更好。 第一次结果
PS. 数据库表现从后端程序的日志中分析的。 第二次结果 不重启Tomcat和Artemis,把数据库的数据恢复后,重启了后端程序
数据库记录数偏少是因为Artemis队列满了,把消息丢掉了。 架构说明从部署拓扑上看,架构分为4个部分:
ActiveMQ ArtemisActiveMQ Artemis是JBoss把HornetQ捐赠到Apache基金会后改名的项目,目前是ActiveMQ下的子项目。 HornetQ是当年大名鼎鼎的高性能消息中间件,因此ActiveMQ Artemis也具备相当的性能表现。 本项目利用它做webapp和backend之间的消息通信。 DisruptorDisruptor是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 VALUE 0 12 (object header) N/A 12 4 int Item.amount N/A 16 4 Long Item.id N/A 20 4 (loss due to the next object alignment)Instance size: 24 bytesSpace losses: 0 bytes internal + 4 bytes external = 4 bytes total 而 java.lang.Long object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 12 (object header) N/A 12 4 (alignment/padding gap) N/A 16 8 long Long.value N/AInstance size: 24 bytesSpace losses: 4 bytes internal + 0 bytes external = 4 bytes total 假设你有100W商品需要秒杀,那么其占用内存 = 1,000,000 * (24b + 4b + 24b) = 52,000,000b = 49m。仅仅只占49m。 优化项架构上的优化点
和JMS相关的优化点
和JDBC相关的优化点
和Tomcat相关的优化点
流程说明本项目只提供了两个接口:
聪明的读者肯定已经想到了,整个秒杀过程是异步的。 下单流程查询下单结果的流程How-tos |
请发表评论