概述

主从复制就是，主机数据更新后，自动同步到备机的master/slaver机制，master以写为主，slaver以读为主。

好处：

• 读写分离
• 容灾快速恢复（一台服务器宕机了，转到其他服务器）

1
2
3
4
5
6

# 在从机上使用slaveof命令加入主机，host为主机地址，port为主机端口
# slaveof是异步操作，不论成功与否，直接返回OK，然后在后台异步与主机连接
slaveof host port

# 查看主从状态
info replication

零钱兑换 II

零钱兑换 II

解题思路

利用动态规划，dp[i]表示金额为i的硬币组合数，边界条件是dp[0] = 1，表示组成金额0有一种组合数。

• 初始化：dp[0] = 1
• 遍历coins，对于其中的每个元素coin：
  • 遍历i从coin到amount，dp[i] += dp[i-coin]
• dp[amount]为最终答案

解题代码

1
2
3
4
5
6
7
8
9
10
11
12

func change(amount int, coins []int) int {
    dp := make([]int, amount+1)     // dp[i]表示组成金额i的组合数
    dp[0] = 1

    for _, coin := range coins {
        for i := coin; i <= amount; i++ {
            dp[i] += dp[i-coin]
        }
    }

    return dp[amount]
}

MySQL中利用锁来保证事务的隔离性，对并发操作进行控制。同时，锁冲突也是影响数据库并发访问性能的重要因素。

并发问题的解决

脏写

对于两个事务都进行写数据（写-写情况）的操作，可能会产生脏写问题，这是任何一种隔离级别都不允许这种问题的发生的。

所以在多个未提交事务相继对一条记录做改动时，需要让它们排队执行（通过锁实现）。

脏读 不可重复读 幻读

对于一个事务进行读取操作，一个事务进行写数据的操作（读-写情况），可能会产生脏读、不可重复读和幻读的问题。对于这些问题，有两种解决方案。

方案一：读操作利用多版本并发控制MVCC，写操作进行加锁

所谓MVCC，就是生成一个ReadView，通过ReadView找到符合条件的记录版本。查询语句只能读到生成ReadView之前已提交事务所做的更改。而写操作肯定针对的是最新的版本信息，读记录的历史版本和改动记录的最新版本并不冲突，也就是采用MVCC时，读-写并不冲突。

普通的SELECT语句在READ COMMITTED和REPEATABLE READ隔离级别下会使用到MVCC读取记录：

• 在READ COMMITTED隔离级别下，一个事务在执行过程中每次执行SELECT操作时都会生成一个ReadView，ReadView的存在本身就保证了事务不可以读取到未提交的事务所做的更改，也就是避免了脏读现象。
• 在REPEATABLE READ隔离级别下，一个事务在执行过程中只有第一次执行SELECT操作才会生成一个ReadView，之后的SELECT操作都复用这个ReadView，这样也就避免了不可重复读和幻读的问题。

Redis提供了两种不同形式的持久化方式：

• RDB（Redis Database）
• AOF（Append Only File）

RDB（Redis Database）

RDB持久化指在指定的时间间隔内将内存中的数据集快照写入磁盘。它也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为dump.rdb

对于RDB来说，提供了三种机制：

• save
• bgsave
• 自动化

save

save会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。

bgsave

Redis会fork一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。阻塞只发生在fork阶段，一般时间很短。

事务的隔离性由锁机制实现。

而事务的原子性、一致性和持久性由事物的redo日志和undo日志来保证。

• redo日志（重做日志）：提供再写入操作，恢复提交事务修改的页操作，用来保证事务的持久性（如在内存中修改还没来得及写入磁盘中，此时系统宕机，就需要redo日志来保证修改写入到磁盘中）
• undo日志（回滚日志）：回滚行记录到某个特定版本，用来保证事务的原子性、一致性

undo日志不是redo日志的逆过程，redo和undo都可以是看作是恢复操作：

• redo日志：是存储引擎层生成的日志，记录的是物理级别上的页修改操作，主要为了保证数据的可靠性
• undo日志：是存储引擎层生成的日志，记录的是逻辑操作日志，如对某个表进行了INSERT操作，那么undo日志就记录一条与之相反的DELETE操作。主要用于回滚和一致性非锁定读

redo日志

InnoDB是以页为单位来管理存储空间的。在访问页面时，需要先把磁盘上的页缓存到内存中的缓冲池中，所有的修改必须先更新缓冲池中的数据，然后缓冲区中的脏页（写入缓冲池但还没有写回磁盘的页）以一定频率被刷新到磁盘中。

为什么需要redo日志

若有这样一种场景，当事务提交后，刚写完缓冲池还没来得及将修改写回磁盘，数据库宕机了，那么这段数据就丢失了。

但是，事务包含了持久性的特点，对于一个已经提交的事务，在事务提交后即使系统发生了崩溃，这个事务对数据库中所做的更改也不能丢失。

所以，这就引入了redo日志：只需要把修改了哪些东西记录一下就好。InnoDB的事务采用了WAL（Write-Ahead Logging）技术，这种技术的思想就是先写日志（redo日志），再写磁盘，只有日志成功写入，事务才算提交成功。当服务器宕机还未刷新磁盘时，可以通过redo日志恢复，以保证事务的持久性。

事务概述

事务定义

Redis事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

Redis事务的主要作用就是串联多个命令防止别的命令插队。

multi exec discard命令

从输入multi命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入exec后，Redis会将之前的命令队列中的命令依次执行。

组队的过程中可以通过discard来放弃组队。

Bitmaps

介绍

Bitmaps数据类型提供了对比特位的操作：

• Bitmaps其实不是一种新的数据类型，本质上它就是字符串，但是它可以对字符串的位进行操作

常用命令

• setbit <key> <offset> <value>：设置Bitmaps中某个偏移量的值

• getbit <key> <offset>：获取Bitmaps中某个偏移量的值

• bitcount <key> [start end]：统计字符串从start字节到end字节比特值为1的数量

• bitop and(or/not/xor) <destkey> [key…]：对多个Bitmaps进行与、或、非、异或运算

HyperLogLog

介绍

HyperLogLog用于做基数（基数就是集合中不同元素的个数）统计，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的。

但是，HyperLogLog只会根据输入元素来计算基数，而不会储存输入元素本身，所以HyperLogLog不能像集合那样，返回输入的各个元素。

常用命令

• pfadd <key> < element> [element ...]：添加指定元素到HyperLogLog中

• pfcount <key> [key ...]：计算多个HyperLogLog中的近似基数

• pfmerge <destkey> <sourcekey> [sourcekey ...]：将一个或多个HyperLogLog合并后存储在另一个HyperLogLog中

Geospatial

Geospatial类型用于记录地理位置信息，即经纬度坐标。

Redis的发布订阅

Redis提供了发布订阅功能，可以用于消息传输。

发布订阅架构

发布订阅机制包括三个部分：发布者、订阅者和channel：

发布者和订阅者都是Redis客户端，Channel则为Redis服务器端，发布者将消息发送到某个的频道，订阅了这个频道的订阅者就能接收到这条消息。一个订阅者可以订阅多个chanel。

最长重复子数组

最长重复子数组

解题思路

利用动态规划的思想，dp[i][j]表示以nums1[i]和nums2[j]为结尾的最长公共后缀的长度。

• 初始化为：
  • 若nums1[i] == nums2[0]，则dp[i][0] = 1，否则为0
  • 若nums1[0] == nums2[j]，则dp[0][j] = 1，否则为0
• 状态转移方程：若nums1[i] == nums2[j]，dp[i][j] = dp[i-1][j-1]+1，否则为0

事务概述

InnoDB是支持事务的

基本概念

事务：一组逻辑操作单元，使数据从一种状态变换到另一种状态

事务处理的原则：保证所有事务都作为一个工作单元来执行，即使出现了故障，都不能改变这种执行方式。当在一个事务中执行多个操作时，要么所有的事务都被提交( commit )，那么这些修改就永久地保存下来；要么数据库管理系统将放弃所作的所有修改，整个事务回滚（rollback ）到最初状态。

事务的ACID特性

ACID即原子性（atomicity）、一致性（consistency）、隔离性（isolation）和持久性（durability）

• 原子性（atomicity）：事务是一个不可分割的工作单位，要么全部提交，要么全部失败回滚。
• 一致性（consistency）：事务执行前后，数据从一个合法性状态变换到另外一个合法性状态。这样的合法性状态不是语法上的，而是和具体业务有关的。
• 隔离性（isolation）：事务的隔离性是指一个事务的执行不能被其他事务干扰，即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。
• 持久性（durability）：一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来的其他操作和数据库故障不应该对其有任何影响。持久性是通过事务日志来保证的。日志包括了重做日志和回滚日志。当我们通过事务对数据进行修改的时候，首先会将数据库的变化信息记录到重做日志中，然后再对数据库中对应的行进行修改。这样做的好处是，即使数据库系统崩溃，数据库重启后也能找到没有更新到数据库系统中的重做日志，重新执行，从而使事务具有持久性。