作者：桦仔
10余年DBA工作经验，
微信：debolop
QQ交流群：740052625
公众号：数据库实战派
前言
大家知道，内存优化表作为In-Memory OLTP功能是从SQL Server 2014开始引入，用来对抗Oracle 12C的In-Memory OLTP选件
不过SQL Server的In-Memory OLTP功能是完全内置的功能，不像Oracle需要额外付费才能获得
由于是比较新的技术，可能大家对内存优化表还是比较陌生，网上也鲜有内存优化表使用场景的文章
朋友公司做的业务是跟蜂鸟配送类似的配送业务，整个配送系统平台每天订单量超过30W
坐标问题
系统中某一个部分需要保存跑男的坐标
坐标需要保存到redis和数据库，一旦坐标更新也需要更新redis中的数据
刚开始朋友用传统表来保存坐标数据，但是很快遇到问题，传统表在更新的速度跟不上
后来改用内存优化表，使用了之后
刚开始上传坐标的接口，延迟很大，用了内存表，100毫秒以内，搞定
这些坐标是需要持久化的，而内存优化表是完全支持ACID的，所以也不需要担心数据丢失的问题
内存优化表更新速度快的另一个原因：无锁机制， 并发（如闩锁争用或阻塞）影响的应用程序迁移到内存中 OLTP 时，其性能会显著提高。
大家知道，内存优化表需要有一个非聚集哈希主键索引，大概的表结构是
每个跑男占用一行记录
对应到redis里面大家应该都知道怎麽存储了吧，使用redis的散列类型来存储跑男的坐标
hmset 跑男ID X坐标 value Y坐标 value 跑男在线时间 valuehmset 1 X坐标 12 Y坐标 10 跑男在线时间 60
因为数据库高可用的问题，朋友就购置了新服务器，用来搭建AlwaysOn，新服务器都用SSD固态硬盘
内存优化表的瓶颈主要在事务日志固化，虽然有延迟持久化，但是延迟持久化在意外宕机的时候可能丢失部分数据
现在新服务器使用SSD固态硬盘之后，事务日志固化的瓶颈基本消失
使用新服务器之后，支撑30w/日订单是完全没有问题的
另一个问题是AlwaysOn
辅助副本上的内存优化表数据是完全没有丢失的，SQL Server 2016对AlwaysOn集群的内存优化表做了改进，支持在辅助副本上查询内存优化表数据
总结
实际上，如果大家对内存优化表研究比较深入的话，内存优化表实际上相当于把redis嵌入到SQL Server，再在上面加上事务等关系型数据库特性，因为两者实现的底层都是哈希表
参考文章
https://www.cnblogs.com/gered/p/12925354.html
https://blog.csdn.net/qq1507171150/article/details/129610993
https://blog.csdn.net/kk185800961/article/details/49211011
加入我们的微信群，与我们一起探讨数据库技术，以及SQL Server、 MySQL、PostgreSQL、MongoDB 的相关话题。
微信群仅供学习交流使用，没有任何广告或商业活动。
