该楼层疑似违规已被系统折叠 隐藏此楼查看此楼

锁表事务问题

锁类型

for update,lock in share mode,next-key locks,mvcc

forupdat e时候，id为主键，RR策略时候，锁住了的条件符合的行，但是如果条件找不到任何 列，锁住的是整个表，(主键，唯一索引，非唯一索引，(insert,updat e对于gab锁不通)

可重复读和提交读本来就是矛盾的，如果可重复读了看不到其他事务的提交；如果可提交 读，两次读取的就不一样，不是重复读。

默认的可重读中，加入了next-keylocks。可重读并不保证避免幻读。

mysql可重读为了防止幻读，加入了forupdate,lockin share mode;普通读的select存在 幻读。

数据隔离级别

隔离级别 脏读 重复读 幻读

读未提交(Readuncommitted) V V V

读已提交(Readcommitted) X V V

可重复读(Repeatableread) X X V

可串行化(Serializable) X X X

数据隔离级别

Read Uncommitted］读取未提交内容)

未提交的事务读取,很少用

Read Committed(读取提交内容)

提交的内容读取,并发读取时如果有事务提交，内容不一致

Repeatable Read(可重读)

确保并发时一致，但是会出现幻读

Serializable(可串行化)

添加并发控制，解决幻读问题;加的共享锁，最高级别可能导致大量的超时现象和锁竞争 幻读(Phantom Read):读取时有新的内容加入.

中间件2题

12. redis 原理

• redis为什么快

使用单线程操作，由于是直接对内存操作，单线程不需要考虑上下文切换，锁竞争等. 极限在cpu的缓存读取,cpu速度特别快，所以单线程就够了，影响redis速度的，多是网络消 耗,持久化过程； 所以redis适合部署在少核缓存快速CPU的cpu机器上.

•持久化方式

master是无阻塞的,slave是阻塞的,slave在同步时不能响应客户端查询；

可以配置master不持久化,slav e持久化，但是有延迟； redis有自己的虚拟内存，因为Linux的虚拟内存page太大(已经弃用) Snapshotting(快照)默认方式；

父子进程操作，父进程接受client操作，子进程持久化;有写入的话父进程直接写入临时区 域；

临死区域完事后替换掉原来的快照文件.此时就需要两倍的相同的内存. 每次是做全部的数据完整写入硬盘，不是增量很大影响内存.

Append-only file(缩写aof)；

虚拟内存：2.4后已经放弃

diskstore :放弃了虚拟内存方式后

• redis cluster

每个master维护了一个位序列，用bit记录自己是否拥有槽位；

还维护了一个槽位到机器节点映射,16384数组实现,槽位是下标,value是节点

。集群添加过程

各个服务之间meet握手(没有自动发现)；

分配角色，默认是都是master;

槽位指派，迁移槽位内容信息

涉及到的主要的数据结构 clusterstate：集群状态 node s：所有结点 migrating_slots_to :迁出中的槽 importing_slots_from :导入中的槽 slots_to_keys：槽中包含的所有Key,用于迁移Slot时获得其包含的Key slots：Slot所属的结点，用于处理请求时判断Key所在Slot是否自己负责 clusterNode：结点信息

slots：结点负责的所有Slot,用于发送Gossip消息通知其他结点自己负责的 Slot。通过位图方式保存节省空间，16384/8恰好是2048字节，所以槽总数16384 不是随意定的。

clusterLink：与其他结点通信的连接