MYSQL第四次作业

1-什么是CAP?

CAP原则
CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错（Partition-tolerance）。在一个分布式系统中三个要素不可同时具有，只能选择其中两个。

一致性（Consistency）
在分布式系统中，所有节点在同一时刻的数据都是一致的。

可用性（Availability）
在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。即每个请求不管成功与否都能得到响应。

分区容错（Partition-tolerance）
保证系统中任意信息的丢失都不会影响系统的运行。

2-Redis 配置文件中有哪些核心的配置信息?作用分别是什么?

Redis配置文件 redis.conf

#通过命令找到核心配置文件的地址(所在地)
find / -name redis.conf
#在正式访问当前配置文件前,建议复制(备份)一份
cp redis.conf redis.conf.backup
#访问配置文件
vim redis.conf

 UNITS

配置大小单位，开头定义了一些基本的度量单位，只支持 bytes，不支持 bit。大小写不敏感。

 INCLUDES

类似 JSP 程序中的 include，多实例的情况可以把公用的配置文件提取出来。

 NETWORK

bind

默认情况下 bind=127.0.0.1 只能接受本机的访问请求。在不写的情况下，无限制接受任何 IP 地址的访问。

生产环境需要填写你应用服务器的地址。由于服务器是需要远程访问的，所以需要将其注释掉。

注释
bind 127.0.0.1 -::1
并且
protected-mode no

 protected-mode

将本机访问保护模式设置

port

端口号，默认 6379

 tcp-backlog

设置 tcp 的 backlog，backlog 其实是一个连接队列，backlog队列总和 = 未完成三次握手队列 + 已经完成三次握手队列。

在高并发环境下你需要一个高 backlog 值来避免慢客户端连接问题。

 timeout

一个空闲的客户端维持多少秒会关闭，0表示关闭该功能。即永不关闭。

 tcp-keepalive

对访问客户端的一种心跳检测，每 n 秒检测一次。

单位为秒，如果设置为0，则不会进行 Keepalive 检测，建议设置成 60。

 GENERAL

 daemonize

是否为后台进程，即守护进程，用于后台启动，设置为yes。

在yum安装方式中 会自动创建服务启动文件 并自动 存放在后台

 pidfile

存放pid文件的位置，每个实例会产生一个不同的pid文件。

loglevel

指定日志记录级别，Redis 总共支持四个级别：debug、verbose、notice、warning，默认为notice。

四个级别根据使用阶段来选择，生产环境选择 notice 或者warning。

 logfile

日志文件名称

databases

设定库的数量，默认16，默认数据库为0，可以使用 SELECT <dbid>命令在连接上指定数据库id。

 SECURITY

 设置密码

当设置好密码后（即把 requirepass foobared 注解解开），然后使用客户端连接服务器后，在执行 set 命令时，提示需要获取权限。

可以在命令中访问密码的查看、设置和取消。

127.0.0.1:6379> config get requirepass
1) "requirepass"
2) ""
127.0.0.1:6379> config set requirepass "123456"
OK
127.0.0.1:6379> config get requirepass
(error)NOAUTH Authentication required.
127.0.0.1:6379> auth 123456
OK
127.0.0.1:6379> get k1
"v1"
127.0.0.1:6379> config set requirepass ""
OK
127.0.0.1:6379> config get requirepass
1) "requirepass"
2) ""

 CLIENTS

 maxclients

设置redis同时可以与多少个客户端进行连接。默认情况下为10000个客户端。如果达到了此限制，redis则会拒绝新的连接请求，并且向这些连接请求方发出“max number of clients reached”以作回应。

 MEMORY MANAGEMENT

 maxmemory

设置redis可以使用的内存量。一旦到达内存使用上限，redis将会试图移除内部数据，移除规则可以通过maxmemory-policy来指定。

如果redis无法根据移除规则来移除内存中的数据，或者设置了“不允许移除”，那么redis则会针对那些需要申请内存的指令返回错误信息，比如SET、LPUSH等。

但是对于无内存申请的指令，仍然会正常响应，比如GET等。如果你的redis是主redis（说明你的redis有从redis），那么在设置内存使用上限时，需要在系统中留出一些内存空间给同步队列缓存，只有在你设置的是“不移除”的情况下，才不用考虑这个因素。

 maxmemory-policy

用于设置内存达到使用上限后的移除规则。有以下参数可设置：

• volatile-lru：使用LRU算法移除key，只对设置了过期时间的键；（最近最少使用）

• allkeys-lru：在所有集合key中，使用LRU算法移除key

• volatile-random：在过期集合中移除随机的key，只对设置了过期时间的键

• allkeys-random：在所有集合key中，移除随机的key

• volatile-ttl：移除那些TTL值最小的key，即那些最近要过期的key

• noeviction：不进行移除。针对写操作，只是返回错误信息

4.7.3 maxmemory-samples

用于设置样本数量，LRU算法和最小TTL算法都并非是精确的算法，而是估算值，所以你可以设置样本的大小，redis默认会检查这么多个key并选择其中LRU的那个。

一般设置3到7的数字，数值越小样本越不准确，但性能消耗越小。

3-乐观悲观锁的区别?

悲观锁

悲观锁(Pessimistic Lock)顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库就用到了很多这种锁机制，比如行锁，表锁，读锁，写锁等，都是在做操作之前先上锁。

乐观锁

乐观锁(Optimistic Lock)顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。

4-Redis 主从复制原理?

Redis 一般是使用一个 Master 节点来进行写操作，而若干个 Slave 节点进行读操作，Master 和 Slave 分别代表了一个个不同的 Redis Server 实例。

另外定期的数据备份操作也是单独选择一个 Slave 去完成，这样可以最大程度发挥 Redis 的性能，为的是保证数据的弱一致性和最终一致性。

另外，Master 和 Slave 的数据不是一定要即时同步的，但是在一段时间后 Master 和 Slave 的数据是趋于同步的，这就是最终一致性。

全同步过程如下：

• Slave 发送 Sync 命令到 Master。

• Master 启动一个后台进程，将 Redis 中的数据快照保存到文件中。

• Master 将保存数据快照期间接收到的写命令缓存起来。

• Master 完成写文件操作后，将该文件发送给 Slave。

• 使用新的 RDB 或 AOF 文件替换掉旧的 RDB 或 AOF 文件。

• Master 将这期间收集的增量写命令发送给 Slave 端。

增量同步过程如下：

• Master 接收到用户的操作指令，判断是否需要传播到 Slave。

• 将操作记录追加到 AOF 文件。

• 将操作传播到其他 Slave：对齐主从库；往响应缓存写入指令。

• 将缓存中的数据发送给 Slave。