该楼层疑似违规已被系统折叠 隐藏此楼查看此楼
锁表事务问题
锁类型
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:与其他结点通信的连接