SQL SERVER 2014--内存表实现秒杀场景
=====================================
网上针对“秒杀”的解决方案很多,数据拆分化解热点,READPAST解决锁问题,应用程序排队限制并发等等很多方式,各有优缺点,只为证明一句名言:条条大路通罗马。
=====================================
今天拿SQL SERVER 2014的内存表来试水“秒杀”,内存表使用“版本”解决了高并发下锁请求和阻塞的问题,使用HASH索引来处理数据页“热点”的问题,解决了PAGE_LATCH等待,虽然本地编译在本测试中效果不是那么明显,但是聊胜于无。
由于测试代码在别人代码基础上修改而来,就不拿出来共享了,具体实现思路:
1. 使用本地编译存储过程来封装秒杀(实现对库存UPDATE和对秒杀成功订单的INSERT操作)
2. 在步骤1的基础上封装一层,实现重试逻辑,重试相关基础请重击
3. 将秒杀商品拆分到多条记录中,避免单条记录成为热点
4. 将秒杀成功的订单表设计为内存表,避免插入记录时的PAGE_LATCH等待
=========================================
测试环境
Windows版本:Windows Server 2012 企业版
数据库版本:SQL SERVER 2014 企业版
服务器CPU: 4个物理CPU 64个逻辑CPU
服务器内存:128GB
模拟秒杀300000商品,1200个线程模拟并发
测试结果
记录数 | 耗时(毫秒) | 每秒秒杀商品数 |
300 | 2786 | 107681.26 |
100 | 3620 | 82872.93 |
50 | 4363 | 68760.03 |
20 | 5240 | 57251.91 |
10 | 7690 | 39011.70 |
5 | 12266 | 24457.85 |
2 | 31186 | 9619.70 |
1 | 69770 | 4299.84 |
以上测试结果仅供参考!
--=============================================
虽然内存表没有锁阻塞的情况,但是对两个事务更新同一条数据时,只有第一个事务提交后第二个事务才能更新成功,而事务提交受日志写入速度的影响,因此在对单条记录或少量记录更新的时候,磁盘单词写入的时间(Avg. Disk sec/Write) 至关重要,本次测试的服务器上,Avg. Disk sec/Write 平均值在0.05ms到0.09ms之间,因此理论上对单条记录的每秒最大更新次数在1w到2w左右,这也是为什么要拆分成多条记录的原因。
--=============================================
福利依旧是妹子

分类:
SQL Server--2014
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· AI与.NET技术实操系列:基于图像分类模型对图像进行分类
· go语言实现终端里的倒计时
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 分享一个免费、快速、无限量使用的满血 DeepSeek R1 模型,支持深度思考和联网搜索!
· 基于 Docker 搭建 FRP 内网穿透开源项目(很简单哒)
· 25岁的心里话
· ollama系列01:轻松3步本地部署deepseek,普通电脑可用
· 按钮权限的设计及实现