- 博客(16)
- 收藏
- 关注
RSS订阅原创 DDIA 第一章 可靠性，可伸缩性和可维护性
现今很多应用程序都是 数据密集型（data-intensive） 的，而非 计算密集型（compute-intensive） 的。因此 CPU 很少成为这类应用的瓶颈，更大的问题通常来自数据量、数据复杂性、以及数据的变更速度。数据库、消息队列、缓存等工具分属于几个差异显著的类别，为什么要把这些东西放在 数据系统（data system） 的总称之下混为一谈呢？● 数据存储可以被当成消息队列用（Redis），消息队列则带有类似数据库的持久保证（Apache Kafka）。
2022-10-31 15:12:19
174
1
原创 redis第七讲 哨兵机制：主库坏了怎么办？
主库坏了怎么办？？用一个从库作为新的主库。问题解决：哨兵机制即实现主从库自动切换的关键机 制，它有效地解决了主从复制模式下故障转移的这三个问题。哨兵其实就是一个运行在特殊模式下的 Redis 进程，主从库实例运行的同时，它也在运 行。哨兵主要负责的就是三个任务:监控、选主(选择主库)和通知。监控周期性地给所有的主从库发送 PING 命令， 检测它们是否仍然在线运行。如果从库没有在规定时间内响应哨兵的 PING命令，哨兵就 会把它标记为“下线状态”。如果主库也没有在规定时间内响应哨兵的 PIN
2022-07-03 18:10:31
186
原创 redis第六讲 数据同步
主从库：将一份数据同时保存在多个实例上。即使有一个实例出现了故 障，需要过一段时间才能恢复，其他实例也可以对外提供服务。读写分离：读操作:主库、从库都可以接收;写操作:首先到主库执行，然后，主库将写操作同步给从库y？如上图上面那个，会让数据在三个实例上的副本不一致。如果我们非要保持这个数据在三个实例上一致，就要涉及到加锁、实例间协商是否完成修改等一系列操作，但这会带来巨额的开销。replicaof 172.16.19.3 6379 变成172.16.19.3的从库。第一次同步：主从级联模式分担
2022-07-03 18:09:06
882
原创 redis第五讲 内存快照
正因为记录的是操作命令，而不是实际的数据，所以，用 AOF 方法进行故障恢复 的时候，需要逐一把操作日志都执行一遍。如果操作日志非常多，Redis 就会恢复得很慢。RDB：和 AOF 相比，RDB 记录的是某一时刻的数据，并不是操作，所以，在做数据恢复时，我 们可以直接把 RDB 文件读入内存，很快地完成恢复。给哪些数据做快照？Redis 的数据都在内存中，为了提供所有数据的可靠性保证，它执行的是全量快照，也就 是说，把内存中的所有数据都记录到磁盘会阻塞主线程吗？Redis 提供了两个命令来生成
2022-07-03 18:02:15
506
原创 redis第四讲 持久化
Redis 的持久化主要有两大机制，即 AOF 日志和 RDB 快照AOF是写后日志传统数据库的日志，例如 redo log(重做日志)，记录的是修改后的数据，而 AOF 里记 录的是 Redis 收到的每一条命令，这些命令是以文本形式保存的。为什么写后？AOF两个风险三种写回策略：Always，同步写回:每个写命令执行完，立马同步地将日志写回磁盘;Everysec，每秒写回:每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘;No，操作系统控制的写回:每个
2022-07-03 17:54:27
93
原创 redis第三讲 redis为什么快？
并发访问控制一直是多线程开发中的一个难点问题，如果没有精细的设计，比如说，只是简单地采用一个粗粒度互斥锁，就会出现不理想的结果:即使增加了线程，大部分线程也在等待获取访问共享资源的互斥锁，并行变串行，系统吞吐率并没有随着线程的增加而增加。而且，采用多线程开发一般会引入同步原语来保护共享资源的并发访问，这也会降低系统 代码的易调试性和可维护性。一方面，Redis 的大部分操作在内存上完成，再加上它采用了高效的数据结构，例如哈希 表和跳表，这是它实现高性能的一个重要原因。另一方面，就是 Redis 采用了多路
2022-07-03 17:51:12
55
原创 mysql 第三讲 事务隔离
原子性、一 致性、隔离性、持久性。为了解决脏读，幻读，不可重复读。脏读：原本的数据比较干净、纯粹，此时由于B事务更改了它，这个数据变得不再纯粹。这个时候A事务立即读取了这个脏数据，但事务B良心发现，又用回滚把数据恢复成原来干净、纯粹的样子，而事务A却什么都不知道，最终结果就是事务A读取了此次的脏数据，称为脏读。不可重复读：由整个事务A比较大，前后读取同一条数据需要经历很长的时间 。而在事务A第一次读取数据，比如此时读取了小明的年龄为20岁，事务B执行更改操作，将小明的年龄更改为30岁，此时事务A第二次读
2022-07-03 17:42:36
48
原创 mysql 第六讲 全局锁和表锁
全局锁就是对整个数据库实例加锁。MySQL提供了一个加全局读锁的方法，命令是 Flush tables with read lock (FTWRL)。之后其他线程的以下语句会被阻塞:数据更新语句(数据的增删改)、数据定义语句(包括 建表、修改表结构等)和更新类事务的提交语句。坏处：如果你在主库上备份，那么在备份期间都不能执行更新，业务基本上就得停摆;如果你在从库上备份，那么备份期间从库不能执行主库同步过来的binlog，会导致主从延迟。如果不加锁：备份系统备份的得到的库不是一个逻辑时间点，这个视图是
2022-06-27 21:07:41
289
原创 mysql 第五讲 深入浅出索引（下）
回到主键索引树搜索的过程，我们称为回表 。 有没有可能经过索引优化，避免回表过程呢?覆盖索引如果执行的语句是select ID（主键） from T where k between 3 and 5，这时只需要查ID的值，而ID的值 已经在k索引树上了。就可以直接使用结果。 是否有必要将身份 证号和名字建立联合索引? 如果现在有一个高频请求，要根据市民的身份证号查询他的姓名，这个联合索引就有意义了 。可以在这个高频请求上用覆盖索引。最左前缀原则当你的
2022-06-27 21:05:02
83
原创 mysql 第四讲 深入浅出索引（上）
哈希表：只适用等值查询。有序数组：在等值查询和范围查询场景中的性能就都非常优秀。等值：O(log(N))。二叉树：不如N叉树。以InnoDB的一个整数字段索引为例，这个N差不多是1200。这棵树高是4的时候，就可以存 1200的3次方个值，这已经17亿了。考虑到树根的数据块总是在内存中的，一个10亿行的表上一 个整数字段的索引，查找一个值最多只需要访问3次磁盘。InnoDB用B+树，分裂操作费时。自增主键的好处：...
2022-06-27 21:02:32
174
原创 mysql 第三讲 事务隔离
原子性、一 致性、隔离性、持久性。为了解决脏读，幻读，不可重复读。脏读：原本的数据比较干净、纯粹，此时由于B事务更改了它，这个数据变得不再纯粹。这个时候A事务立即读取了这个脏数据，但事务B良心发现，又用回滚把数据恢复成原来干净、纯粹的样子，而事务A却什么都不知道，最终结果就是事务A读取了此次的脏数据，称为脏读。不可重复读：由整个事务A比较大，前后读取同一条数据需要经历很长的时间 。而在事务A第一次读取数据，比如此时读取了小明的年龄为20岁，事务B执行更改操作，将小明的年龄更改为30岁，此时事务A第二次读
2022-06-27 21:00:25
96
原创 mysql 第二讲 一条sql更新语句是如何执行的
为什么？这是为了让两份日志之间的逻辑一致。数据恢复：首先，找到最近的一次全量备份，如果你运气好，可能就是昨天晚上的一个备份，从这个备份恢复到临时库;然后，从备份的时间点开始，将备份的binlog依次取出来，重放到误删表之前的那个时刻。如果不是两阶段，数据恢复就会出问题。先写redo log后写binlog：这时候binlog里面就没有记录这个语句。由于这个语句的binlog丢失，这 个临时库就会少了这一次更新，恢复出来的这一行c的值就是0，与原库的值不同。先写binlog后写redo log：
2022-06-27 20:57:54
109
原创 Mysql 第一讲 基础架构
server：涵盖MySQL的大多数核心服务 功能，以及所有的内置函数(如日期、时间、数学和加密函数等)，所有跨存储引擎（指的应该是和存储引擎无关）的功能都在这一层实现，比如存储过程、触发器、视图等。建立连接的过程通常是比较复杂的，所以我建议你在使用中要尽量减少建立连接的动作，也就是 尽量使用长连接。...
2022-06-27 20:53:52
106
原创 redis第二讲 redis数据结构
redis为什么快：一方面，这是因为它是内存数据库， 所有操作都在内存上完成，内存的访问速度本身就很快。另一方面，这要归功于它的数据结构。这是因为，键值对是按一定的数据结构来组织的，操作键值对最终就是对数据结构 进行增删改查操作，所以高效的数据结构是 Redis 快速处理数据的基础。为了实现从键到值的快速访问，Redis 使用了一个哈希表来保存所有键值对。哈希桶中的元素保存的并不是值本身，而是指向具体值的指针。当哈希表里写入的数据越来越多，redis会做rehash操作（增加现有的哈希桶的数量）。...
2022-06-23 17:46:27
264
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人