memcached写数据时存在并发问题吗
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了memcached写数据时存在并发问题吗相关的知识，希望对你有一定的参考价值。
1、性能都比较高，性能对我们来说应该都不是瓶颈总体来讲，TPS方面redis和memcache差不多2、操作的便利性memcache数据结构单一redis丰富一些，数据操作方面，redis更好一些，较少的网络IO次数3、内存空间的大小和数据量的大小redis在2.0版本后增加了自己的VM特性，突破物理内存的限制；可以对keyvalue设置过期时间（类似memcache）memcache可以修改最大可用内存,采用LRU算法4、可用性（单点问题）对于单点问题，redis，依赖客户端来实现分布式读写；主从复制时，每次从节点重新连接主节点都要依赖整个快照,无增量复制，因性能和效率问题，所以单点问题比较复杂；不支持自动sharding,需要依赖程序设定一致hash机制。一种替代方案是，不用redis本身的复制机制，采用自己做主动复制（多份存储），或者改成增量复制的方式（需要自己实现），一致性问题和性能的权衡Memcache本身没有数据冗余机制，也没必要；对于故障预防，采用依赖成熟的hash或者环状的算法，解决单点故障引起的抖动问题。5、可靠性（持久化）对于数据持久化和数据恢复，redis支持（快照、AOF）：依赖快照进行持久化，aof增强了可靠性的同时，对性能有所影响memcache不支持，通常用在做缓存,提升性能；6、数据一致性（事务支持）Memcache在并发场景下，用cas保证一致性redis事务支持比较弱，只能保证事务中的每个操作连续执行7、数据分析不支持8、应用场景redis：数据量较小的更性能操作和运算上memcache：用于在动态系统中减少数据库负载，提升性能;做缓存，提高性能（适合读多写少，对于数据量比较大，可以采用sharding） 参考技术A memcache 本身是一款分布式的高速缓存系统，以 key-value 的形式常驻内存，一般用来做网站或者数据库的缓存使用。特别是对以下场景非常适合用 memcache 来做缓存：
1. 频繁访问的数据
2. 安全性要求比较低的数据
3. 更新比较频繁的小表（用户状态表、物品库存等）
mysql memcached api MySQL 5.6 —— 开始支持MySQL 5.6 把 memcache 功能以插件形式集成到 MySQL 数据库中，称为 memcached api。这样一来，memcache 的数据以 InnoDB 关系表的形式同步于磁盘，解决了 memcache 的几个问题：
1. 解决了 memcache 的数据持久化的问题；
2. 可以很方便的以 SQL 语句的形式直接访问 memcache 的数据；
3. 不需要单独安装 memcache，安装 MySQL 即可使用。
MySQL 5.7 —— 深入优化
MySQL 5.7 对 memcached api 做了深入优化，官方数据显示使用 memcached api，在只读的场景中，QPS 提升到 100W。
MySQL 8.0 —— 新增特性
MySQL 8.0 发布后，又在功能上给 memcached api 增加了两个新特性。1. 批量获取 KEY相比原来一次只能读取一个 Key 来讲，减少了客户端与 MySQL 服务端的数据交互次数。2. 可以对 KEY 进行 RANGE 操作
可以直接类似于 select * from t1 where id between 10 and 20 这样的范围检索语句。 参考技术B ASAS ZXZxz ZXzxzAAAa
かいわ面试官 の 两个事务并发写，能保证数据唯一吗？
哟，又是我小白，**面试官就是我，想不到吧。最近有点高产了。
连我自己都害怕了。
直接进入正题吧。
两个事务并发写，能保证数据唯一吗？我先来解释下标题讲的是个啥。
我们假设有这么一个用户注册的场景。用户并发请求注册新用户。
你有一张数据库表，也就是下面的user表。
产品经理要求用户和用户之间，电话号码不能重复，为了保证这一点。我们想到了先查一下数据库，再判断一下，如果存在，就退出，否则插入一条数据。类似下面这样的伪代码。
select user where phone_no =2; // 查询sql
if (user 存在)
return
else
insert user; // 插入sql
但这是两条sql语句，先执行查询sql，判断后再决定要不要执行插入sql。每次用户注册的时候都会执行这么一段逻辑。
那如果，此时有多个用户在做操作，就会并发执行这段逻辑。
如果都并发执行，第一条sql语句执行完之后，都会发现没有用户存在。此时都执行了插入，这样就出现了两条一样的数据才对。
所以，有人就想了，这两条sql语句逻辑应该是一个整体，不应该拆开，于是就想到了事务，通过事务把这两个sql作为一个整体，要么一起执行，要么都回滚。
这正是数据库ACID里的A（Atomicity），原子性的完美体现啊。
伪代码类似下面这样。
begin;
select user where phone_no =2; // 查询sql
if (user 存在)
return
else
insert user; // 插入sql
commit;
那么问题来了，这段逻辑，并发执行，能保证数据唯一？
当然是不能。
事务內的多条sql语句，确实是原子的，要么一起成功，要么一起失败，这没错，但跟这个场景没什么太大关系。事务是并发执行的，第一个事务执行查询用户，并不会阻塞另一个事务查询用户，所以都有可能查到用户不存在，此时两个事务逻辑都判断为用户不存在，然后插入数据库。事务内两条sql都执行成功了，于是就插入了两条一样的数据。
那么我们接下来聊聊，怎么保证上面这种场景下，插入的数据是唯一的。方法有很多种，但我们今天只讨论mysql内部的做法，不考虑其他外部中间件（比如redis分布式锁这些）。
唯一索引通过下面的命令，可以为数据库user表的phone_no字段加入唯一索引。
ALTER TABLE `user` ADD unique(`phone_no`);
我们执行一条写操作时，比如下面这句，
INSERT INTO `user` (`user_name`, `phone_no`) VALUES(\'小红\', 2);
第一次会插入成功，第二次再执行插入，则会出现报错。
Duplicate entry \'2\' for key \'phone_no\'
含义是phone_no这个字段是唯一的，加两次phone_no=2会导致重复。
于是乎回到我们文章开头的场景里，就完美解决了重复插入的问题了。
那么问题来了。
为什么唯一索引能保证数据唯一？
我们看看一句写操作，会经历什么。
首先，mysql作为一个数据库，内部主要分为两层，一层是server层，一层是存储引擎层（一般是innodb）。
server层主要管的是数据库链接，权限校验，以及sql语句校验和优化之类的工作。请求打到存储引擎层，才是真正的查询和更新数据的操作。
大家都知道数据库是持久化存储，且最后都是把数据存到磁盘上的。
那数据库读写是直接读写磁盘数据吗？
不是，如果直接读写磁盘的话，那就太慢了，为了提升速度。
它在磁盘前面加了一层内存，叫buffer pool。它里面有很多细节，但最主要的就是个双向链表，里面放的是一个个数据页，每个数据页的大小默认是 16kb，数据页里面放的就是磁盘的数据。
于是有了这层buffer pool内存，mysql的读和写操作都可以先操作这部分内存，如果想要读写的数据页不在buffer pool里，再跑到磁盘里去捞。由于读写内存的速度比读写磁盘快得多。
所以引擎读写都快多了。
但这还不够，很多时候写操作，我的诉求就是把xx更新为xx，或插入xx，数据库光知道这一点就够了，我根本不需要知道数据页原来长什么样子。
有点抽象？举个例子吧。
比方说我想要把id=1的这条数据的phone_no字段更新为100，数据库知道这一点就够了，至于这条数据原来phone_no究竟是等于20，还是30，这根本不重要，反正最后都会变成我想要的phone_no=100。
也就是说，如果有那么一块内存，记录下我准备把数据改成什么样子，然后后续异步慢慢更新到磁盘数据上。那我甚至到不需要在一开始就把这块数据从磁盘读到buffer pool中，按照这个思路，change buffer就来了。
于是乎，写加了普通索引的数据，它只要把想要写的内容写到change buffer上，就立马结束返回了。后面innodb引擎拿着这个change buffer，再异步读入磁盘数据到内存，将change buffer的数据修改到数据页中，再写回磁盘，这速度就上来了，秒啊。
但这个change buffer，放在唯一索引这里就不管用了，毕竟，它得保证数据真的只有一条，那就得去看下数据库里，是不是真的有这条数据。
所以，对于insert场景，普通索引把需求扔到change buffer就完事返回了，而唯一索引需要真的把数据从磁盘读到内存来，看下是不是有重复的，没重复的再插入数据。
这唯一索引，在性能上就输了一截了。
所以回到唯一索引为什么能保证数据唯一的问题上，一句话概括就是，唯一索引会绕过change buffer，确保把磁盘数据读到内存后再判断数据是否存在，不存在才能插入数据，否则报错，以此来保证数据是唯一的。
上面之所以写入时数据不能保证唯一是因为有两个事务在同时并发操作。
mysql有四层隔离级别，应对不同的事务并发处理能力。之前写的《mysql主库更新后，从库都读到最新值了，主库还有可能读到旧值吗？》,里面用一个例子简单介绍了他们之间的区别。
其中，串行化（serializable）隔离级别，正好从效果上来看，事务们都是依次执行的，这样就不存在并发问题了。
于是，执行逻辑成了下面这样。
所以也能保证只插入一条数据。
这方案生产中能用吗？
这个方案虽然确实能保证只插入一条数据，但生产中不建议这么用，性能比较差，用了可能会被同事喷。但是如果一定要用，可以只将当前数据库连接会话（session）改为串行化，而不是将全局（global）改为串行化。这样就不会影响到其他会话的事务隔离级别。
// 修改当前会话为串行化
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;
// 查看当前会话的事务隔离级别
select @@tx_isolation;
// 输出 SERIALIZABLE
// 查看全局事务隔离级别
select @@global.tx_isolation;
// 输出 REPEATABLE-READ
加唯一索引可以保证数据并发写入时数据唯一，而且最省事省心。
数据库通过引入一层buffer pool内存来提升读写速度，普通索引可以利用change buffer提高数据插入的性能。
唯一索引会绕过change buffer，确保把磁盘数据读到内存后再判断数据是否存在，不存在才能插入数据，否则报错，以此来保证数据是唯一的。
更改隔离级别为串行化，也能实现并发写入时数据唯一。
给大家留个问题呗，前面也提到了，innodb中，利用了change buffer，为普通索引做了加速。有没有哪些场景下，change buffer不仅不能给普通索引加速，还起到反作用的呢？
最后大家也别笑，文章开头提到的通过开事务来保证数据唯一性的错误操作，其实很容易犯，而且我曾经也遇到过不止一次这样的事情。
做这个操作的人，还会信誓旦旦，言之凿凿的说出他的理解，在我解释了几遍发现无果之后，我选择低头假装思考，然后说："你说的有点道理，我再回去好好想想"，然后默默的为数据表加上唯一索引……
我相信对方肯定已经理解了。那一刻，我感觉我写的不是代码，我写的是人情世故。
别说了，一起在知识的海洋里呛水吧
点击下方名片，关注公众号:【小白debug】
不满足这点知识？网管为大家整理了一本超实用的《Go 开发参考书》收集了70多条开发实践。去我的公众号回复【gocookbook】即刻领取！
扫码关注公众号「网管叨bi叨」
给网管个星标，第一时间吸我的知识 以上是关于memcached写数据时存在并发问题吗的主要内容，如果未能解决你的问题，请参考以下文章