数据库和缓存面试题

数据库和缓存面试题

1.列举常见的关系型数据库和非关系型都有那些？

关系型数据库：

Oracle、DB2、Microsoft SQL Server、Microsoft Access、MySQL

非关系型数据库：

NoSql、Cloudant、MongoDb、redis、HBase

两种数据库之间的区别：

关系型数据库

关系型数据库的特性

1、关系型数据库，是指采用了关系模型来组织数据的数据库；

2、关系型数据库的最大特点就是事务的一致性；

3、简单来说，关系模型指的就是二维表格模型，而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织**。**

关系型数据库的优点

1、容易理解：二维表结构是非常贴近逻辑世界一个概念，关系模型相对网状、层次等其他模型来说更容易理解；
　　2、使用方便：通用的SQL语言使得操作关系型数据库非常方便；
　　3、易于维护：丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了数据冗余和数据不一致的概率；
　　4、支持SQL，可用于复杂的查询。

关系型数据库的缺点

1、为了维护一致性所付出的巨大代价就是其读写性能比较差；
　　2、固定的表结构；
　　3、高并发读写需求；
　　4、海量数据的高效率读写；

非关系型数据库

非关系型数据库的特性

1、使用键值对存储数据；
　　2、分布式；
　　3、一般不支持ACID特性；
　　4、非关系型数据库严格上不是一种数据库，应该是一种数据结构化存储方法的集合。

非关系型数据库的优点

1、无需经过sql层的解析，读写性能很高；
　　2、基于键值对，数据没有耦合性，容易扩展；
　　3、存储数据的格式：nosql的存储格式是key,value形式、文档形式、图片形式等等，文档形式、图片形式等等，而关系型数据库则只支持基础类型。

非关系型数据库的缺点

1、不提供sql支持，学习和使用成本较高；
　　 2、无事务处理，附加功能bi和报表等支持也不好；

2.MySQL常见数据库引擎及比较？

MySQL存储引擎简介

MySQL支持数个存储引擎作为对不同表的类型的处理器。MySQL存储引擎包括处理事务安全表的引擎和处理非事务安全表的引擎：

MyISAM管理非事务表。它提供高速存储和检索，以及全文搜索能力。MyISAM在所有MySQL配置里被支持，它是默认的存储引擎，除非你配置MySQL默认使用另外一个引擎。

MEMORY存储引擎提供“内存中”表。MERGE存储引擎允许集合将被处理同样的MyISAM表作为一个单独的表。就像MyISAM一样，MEMORY和MERGE存储引擎处理非事务表，这两个引擎也都被默认包含在MySQL中。

注：MEMORY存储引擎正式地被确定为HEAP引擎。

InnoDB和BDB存储引擎提供事务安全表。BDB被包含在为支持它的操作系统发布的MySQL-Max二进制分发版里。InnoDB也默认被包括在所 有MySQL 5.1二进制分发版里，你可以按照喜好通过配置MySQL来允许或禁止任一引擎。
EXAMPLE存储引擎是一个“存根”引擎，它不做什么。你可以用这个引擎创建表，但没有数据被存储于其中或从其中检索。这个引擎的目的是服务，在 MySQL源代码中的一个例子，它演示说明如何开始编写新存储引擎。同样，它的主要兴趣是对开发者。

NDB Cluster是被MySQL Cluster用来实现分割到多台计算机上的表的存储引擎。它在MySQL-Max 5.1二进制分发版里提供。这个存储引擎当前只被Linux, Solaris, 和Mac OS X 支持。在未来的MySQL分发版中，我们想要添加其它平台对这个引擎的支持，包括Windows。

ARCHIVE存储引擎被用来无索引地，非常小地覆盖存储的大量数据。

CSV存储引擎把数据以逗号分隔的格式存储在文本文件中。

BLACKHOLE存储引擎接受但不存储数据，并且检索总是返回一个空集。

FEDERATED存储引擎把数据存在远程数据库中。在MySQL 5.1中，它只和MySQL一起工作，使用MySQL C Client API。在未来的分发版中，我们想要让它使用其它驱动器或客户端连接方法连接到另外的数据源。

如何选择最适合你的存储引擎呢？

MyISAM：默认的MySQL插件式存储引擎，它是在Web、数据仓储和其他应用环境下最常使用的存储引擎之一。注意，通过更改STORAGE_ENGINE配置变量，能够方便地更改MySQL服务器的默认存储引擎。

InnoDB：用于事务处理应用程序，具有众多特性，包括ACID事务支持。(提供行级锁)

BDB：可替代InnoDB的事务引擎，支持COMMIT、ROLLBACK和其他事务特性。

Memory：将所有数据保存在RAM中，在需要快速查找引用和其他类似数据的环境下，可提供极快的访问。

Merge：允许MySQL DBA或开发人员将一系列等同的MyISAM表以逻辑方式组合在一起，并作为1个对象引用它们。对于诸如数据仓储等VLDB环境十分适合。

Archive：为大量很少引用的历史、归档、或安全审计信息的存储和检索提供了完美的解决方案。

Federated：能够将多个分离的MySQL服务器链接起来，从多个物理服务器创建一个逻辑数据库。十分适合于分布式环境或数据集市环境。

Cluster/NDB：MySQL的簇式数据库引擎，尤其适合于具有高性能查找要求的应用程序，这类查找需求还要求具有最高的正常工作时间和可用性。

Other：其他存储引擎包括CSV（引用由逗号隔开的用作数据库表的文件），Blackhole（用于临时禁止对数据库的应用程序输入），以及Example引擎（可为快速创建定制的插件式存储引擎提供帮助）。

MySQL存储引擎比较

MyISAM

​ MyISAM是MySQL的默认存储引擎。MyISAM不支持事务、也不支持外键，但其访问（读）速度快，对事务完整性没有要求。
　　MyISAM除了提供ISAM里所没有的索引和字段管理的大量功能，MyISAM还使用一种表格锁定的机制，来优化多个并发的读写操作，其代价是你需要经常运行OPTIMIZE TABLE命令，来恢复被更新机制所浪费的空间。MyISAM还有一些有用的扩展，例如用来修复数据库文件的MyISAMCHK工具和用来恢复浪费空间的MyISAMPACK工具。MYISAM强调了快速读取操作，这可能就是为什么MySQL受到了WEB开发如此青睐的主要原因：在WEB开发中你所进行的大量数据操作都是读取操作。所以，大多数虚拟主机提供商和INTERNET平台提供商只允许使用MYISAM格式。MyISAM格式的一个重要缺陷就是不能在表损坏后恢复数据。
　　InnoDB存储引擎提供了具有提交、回滚和崩溃恢复能力的事务安全。但是比起MyISAM存储引擎，InnoDB写的处理效率差一些并且会占用更多的磁盘空间以保留数据和索引。

MEMORY/HEAP

MEMORY（又叫HEAP）存储引擎使用存在内存中的内容来创建表。每个MEMORY表只实际对应一个磁盘文件。MEMORY类型的表访问非常得快，因为它的数据是放在内存中的，并且默认使用HASH索引。但是一旦服务关闭，表中的数据就会丢失掉。 HEAP允许只驻留在内存里的临时表格。驻留在内存里让HEAP要比ISAM和MYISAM都快，但是它所管理的数据是不稳定的，而且如果在关机之前没有进行保存，那么所有的数据都会丢失。在数据行被删除的时候，HEAP也不会浪费大量的空间。HEAP表格在你需要使用SELECT表达式来选择和操控数据的时候非常有用。
　　MEMORY主要用于那些内容变化不频繁的代码表，或者作为统计操作的中间结果表，便于高效地堆中间结果进行分析并得到最终的统计结果。

MERGE

MERGE存储引擎是一组MyISAM表的组合，这些MyISAM表必须结构完全相同。MERGE表本身没有数据，对MERGE类型的表进行查询、更新、删除的操作，就是对内部的MyISAM表进行的。 MERGE用于将一系列等同的MyISAM表以逻辑方式组合在一起，并作为一个对象引用它。MERGE表的优点在于可以突破对单个MyISAM表大小的限制，通过将不同的表分布在多个磁盘上，可以有效的改善MERGE表的访问效率。
　　MyISAM与InnoDB的区别
　　InnoDB和MyISAM是许多人在使用MySQL时最常用的两个表类型，这两个表类型各有优劣，视具体应用而定。基本的差别为：MyISAM类型不支持事务处理等高级处理，而InnoDB类型支持。MyISAM类型的表强调的是性能，其执行数度比InnoDB类型更快，但是不提供事务支持，而InnoDB提供事务支持已经外部键等高级数据库功能。
　　MyISAM表还支持3中不同的存储格式： 静态表 、 动态表 、压缩表
　　静态表是默认的存储格式，静态表中的字段都是非变长的字段，优点是：存储非常迅速，容易缓存，出现故障容易恢复；缺点是：占用的空间通常比动态表多。（注意： 在存储时，列的宽度不足时，用空格补足，当时在访问的时候并不会得到这些空格）
　　动态表的字段是变长的，优点是：占用的空间相对较少，但是频繁地更新删除记录会产生碎片，需要定期改善性能，并且出现故障的时候恢复相对比较困难。
　　压缩表占用磁盘空间小，每个记录是被单独压缩的，所以只有非常小的访问开支。
　　InnoDB存储方式为两种：使用共享表空间存储 、使用多表空间

3.简述数据三大范式？

简言之就是，数据库设计对数据的存储性能，还有开发人员对数据的操作都有莫大的关系。所以建立科学的，规范的的数据库是需要满足一些规范的来优化数据数据存储方式。在关系型数据库中这些规范就可以称为范式。（简单来说，就是根据需要，来优化数据存储方式！）

什么是三大范式？

第一范式：当关系模式R的所有属性都不能在分解为更基本的数据单位时，称R是满足第一范式的，简记为1NF。满足第一范式是关系模式规范化的最低要求，否则，将有很多基本操作在这样的关系模式中实现不了。（说白了，就是关系模式R的所有属性不能再分解了，那么R就满足第一范式！）

特性：

1、每一列属性都是不可再分的属性值，确保每一列的原子性

2、两列的属性相近或相似或一样，尽量合并属性一样的列，确保不产生冗余数据。

如果需求知道那个省那个市并按其分类，那么显然第一个表格是不容易满足需求的，也不符合第一范式。

显然第一个表结构不但不能满足足够多物品的要求，还会在物品少时产生冗余。也是不符合第一范式的。

第二范式：如果关系模式R满足第一范式，并且R得所有非主属性都完全依赖于R的每一个候选关键属性，称R满足第二范式，简记为2NF。（说白了，就是非主属性都要依赖于每一个关键属性！）

每一行的数据只能与其中一列相关，即一行数据只做一件事。只要数据列中出现数据重复，就要把表拆分开来。

一个人同时订几个房间，就会出来一个订单号多条数据，这样子联系人都是重复的，就会造成数据冗余。我们应该把他拆开来。

这样便实现一条数据做一件事，不掺杂复杂的关系逻辑。同时对表数据的更新维护也更易操作。

第三范式：设R是一个满足第一范式条件的关系模式，X是R的任意属性集，如果X非传递依赖于R的任意一个候选关键字，称R满足第三范式，简记为3NF.

数据不能存在传递关系，即没个属性都跟主键有直接关系而不是间接关系。像：a–>b–>c 属性之间含有这样的关系，是不符合第三范式的。

比如Student表（学号，姓名，年龄，性别，所在院校，院校地址，院校电话）

这样一个表结构，就存在上述关系。 学号–> 所在院校 --> (院校地址，院校电话)

这样的表结构，我们应该拆开来，如下。

（学号，姓名，年龄，性别，所在院校）–（所在院校，院校地址，院校电话）

4.什么是事务？MySQL如何支持事务？

什么是事务？

事务是由一步或几步数据库操作序列组成逻辑执行单元，这系列操作要么全部执行，要么全部放弃执行。程序和事务是两个不同的概念。一般而言：一段程序中可能包含多个事务。（说白了就是几步的数据库操作而构成的逻辑执行单元）

事务具有四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持续性（Durability）。这四个特性也简称ACID性。

（1）原子性：事务是应用中最小的执行单位，就如原子是自然界最小颗粒，具有不可再分的特征一样。事务是应用中不可再分的最小逻辑执行体。（最小了，不可再分了）

（2）一致性：事务执行的结果，必须使数据库从一个一致性状态，变到另一个一致性状态。当数据库中只包含事务成功提交的结果时，数据库处于一致性状态。一致性是通过原子性来保证的。（说罢了就是白狗变成了黑狗，不能出现斑点狗！）

（3）隔离性：各个事务的执行互不干扰，任意一个事务的内部操作对其他并发的事务，都是隔离的。也就是说：并发执行的事务之间不能看到对方的中间状态，并发执行的事务之间不能相互影响。（说白了，就是你做你的，我做我的！）

（4）持续性：持续性也称为持久性，指事务一旦提交，对数据所做的任何改变，都要记录到永久存储器中，通常是保存进物理数据库。（说白了就是一条道跑到黑）

MySQL如何支持事务？

MYSQL的事务处理主要有两种方法

1.用begin,rollback,commit来实现
　　　　begin开始一个事务
　　　　rollback事务回滚
　　　commit 事务确认
　　2.直接用set来改变mysql的自动提交模式
　　 mysql默认是自动提交的，也就是你提交一个query，就直接执行！可以通过
　　 set autocommit = 0 禁止自动提交
　　 set autocommit = 1 开启自动提交
来实现事务的处理

MySQL要使用InnoDB引擎才能支持事务操作：
START TRANSACTION | BEGIN [WORK]
COMMIT [WORK] [AND [NO] CHAIN] [[NO] RELEASE]
ROLLBACK [WORK] [AND [NO] CHAIN] [[NO] RELEASE]
SET AUTOCOMMIT = {0 | 1}

START TRANSACTION 或 BEGIN 语句：开始一项新的事务。
COMMIT 和 ROLLBACK：用来提交或者回滚事务。
CHAIN 和 RELEASE 子句：分别用来定义在事务提交或者回滚之后的操作，CHAIN 会立即启动一个新事务，并且和刚才的事务具有相同的隔离级别，RELEASE 则会断开和客户端的连接。
SET AUTOCOMMIT 可以修改当前连接的提交方式， 如果设置了 SET AUTOCOMMIT=0，则设置之后的所有事务都需要通过明确的命令进行提交或者回滚

5.简述数据库设计中一对多和多对多的应用场景？

一对一： 比如文章的meta信息（分类、标签、摘要、发布日期等）和文章正文内容；
多对多： 文章和标签

6.如何基于数据库实现商城商品计数器？

如果是在非常高的并发之下，还是建议用内存数据库redis去实现计数的功能。如果不是那么高的并发，用表实现就可以。

方式一： 单独维护一个商品数量表
方式二： 在商品表中用多行来记录商品数量

7.简述触发器、函数、视图、存储过程？

1、视图
视图只是一种逻辑对象，是一种虚拟表，它并不是物理对象，因为视图不占物理存储空间，在视图中被查询的表称为视图的基表，大多数的select语句都可以用在创建视图中（说白了，视图就是一种虚拟表，就像是一张电子照片）
优点：集中用户使用的数据，掩码数据的复杂性，简化权限管理以及为向其他应用程序输出而重新组织数据等
2、触发器
（1）触发器是一个特殊的存储过程，它是MySQL在insert、update、delete的时候自动执行的代码块。
（2）触发器必须定义在特定的表上。
（3）自动执行，不能直接调用，
3、函数
它跟php或js中的函数几乎一样：需要先定义，然后调用（使用）。
只是规定，这个函数，必须要返回数据——要有返回值
4、存储过程
存储过程(procedure)，概念类似于函数，就是把一段代码封装起来，当要执行这一段代码的时候，可以通过调用该存储过程来实现。在封装的语句体里面，可以同if/else ,case,while等控制结构，可以进行sql编程，查看现有的存储过程。

8.MySQL索引种类

1、普通索引

这是最基本的索引，它没有任何限制，比如上文中为title字段创建的索引就是一个普通索引，MyIASM中默认的BTREE类型的索引，也是我们大多数情况下用到的索引。

–直接创建索引
CREATE INDEX index_name ON table(column(length))
–修改表结构的方式添加索引
ALTER TABLE table_name ADD INDEX index_name ON (column(length))
–创建表的时候同时创建索引
CREATE TABLE `table` (
`id` int(11) NOT NULL AUTO_INCREMENT ,
`title` char(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ,
`content` text CHARACTER SET utf8 COLLATE utf8_general_ci NULL ,
`time` int(10) NULL DEFAULT NULL ,
PRIMARY KEY (`id`),
INDEX index_name (title(length))
)
–删除索引
DROP INDEX index_name ON table

2、 唯一索引

与普通索引类似，不同的就是：索引列的值必须唯一，但允许有空值（注意和主键不同）。如果是组合索引，则列值的组合必须唯一，创建方法和普通索引类似。

–创建唯一索引
CREATE UNIQUE INDEX indexName ON table(column(length))
–修改表结构
ALTER TABLE table_name ADD UNIQUE indexName ON (column(length))
–创建表的时候直接指定
CREATE TABLE `table` (
`id` int(11) NOT NULL AUTO_INCREMENT ,
`title` char(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ,
`content` text CHARACTER SET utf8 COLLATE utf8_general_ci NULL ,
`time` int(10) NULL DEFAULT NULL ,
PRIMARY KEY (`id`),
UNIQUE indexName (title(length))
);

3、全文索引（FULLTEXT）

MySQL从3.23.23版开始支持全文索引和全文检索，FULLTEXT索引仅可用于 MyISAM 表；他们可以从CHAR、VARCHAR或TEXT列中作为CREATE TABLE语句的一部分被创建，或是随后使用ALTER TABLE 或CREATE INDEX被添加。对于较大的数据集，将你的资料输入一个没有FULLTEXT索引的表中，然后创建索引，其速度比把资料输入现有FULLTEXT索引的速度更为快。不过切记对于大容量的数据表，生成全文索引是一个非常消耗时间非常消耗硬盘空间的做法。

–创建表的适合添加全文索引
CREATE TABLE `table` (
`id` int(11) NOT NULL AUTO_INCREMENT ,
`title` char(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ,
`content` text CHARACTER SET utf8 COLLATE utf8_general_ci NULL ,
`time` int(10) NULL DEFAULT NULL ,
PRIMARY KEY (`id`),
FULLTEXT (content)
);
–修改表结构添加全文索引
ALTER TABLE article ADD FULLTEXT index_content(content)
–直接创建索引
CREATE FULLTEXT INDEX index_content ON article(content)

4.、单列索引、多列索引
多个单列索引与单个多列索引的查询效果不同，因为执行查询时，MySQL只能使用一个索引，会从多个索引中选择一个限制最为严格的索引。
5.、组合索引（最左前缀）
平时用的SQL查询语句一般都有比较多的限制条件，所以为了进一步榨取MySQL的效率，就要考虑建立组合索引。例如上表中针对title和time建立一个组合索引：ALTER TABLE article ADD INDEX index_titme_time (title(50),time(10))。建立这样的组合索引，其实是相当于分别建立了下面两组组合索引：

–title,time
–title

为什么没有time这样的组合索引呢？这是因为MySQL组合索引“最左前缀”的结果。简单的理解就是只从最左面的开始组合。并不是只要包含这两列的查询都会用到该组合索引，如下面的几个SQL所示：

–使用到上面的索引
SELECT * FROM article WHREE title='测试' AND time=1234567890;
SELECT * FROM article WHREE utitle='测试';
–不使用上面的索引
SELECT * FROM article WHREE time=1234567890;

9.索引在什么情况下遵循最左前缀的规则？

对于组合索引mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配。索引index1:(a,b,c)，只会走a、a,b、a,b,c 三种类型的查询，其实这里说的有一点问题，a,c也走，但是只走a字段索引，不会走c字段。

select * from table where a = ‘1’ and b > ‘2’ and c=‘3’ 这种类型的也只会有a与b走索引，c不会走。
像select * from table where a = ‘1’ and b > ‘2’ and c=‘3’ 这种类型的sql语句，在a、b走完索引后，c肯定是无序了，所以c就没法走索引

10.主键和外键的区别？

主键

定义：唯一标识一条记录，不能有重复的，不允许为空

作用：用来保证数据完整性

个数：主键只能有一个

ALTER TABLE “表名” ADD PRIMARY KEY (字段名)

外键

定义：表的外键是另一表的主键, 外键可以有重复的, 可以是空值

作用：用来和其他表建立联系用的

个数：一个表可以有多个外键

ALTER TABLE “表名” ADD FOREIGN KEY (字段名) REFERENCES “另一张表名”( 字段名)

主键是能确定一条记录的唯一标识，比如，一条记录包括身份正号，姓名，年龄。身份证号是唯一能确定你这个人的，其他都可能有重复，所以，身份证号是主键。
外键用于与另一张表的关联。是能确定另一张表记录的字段，用于保持数据的一致性。

11.MySQL常见的函数？

一、数学函数
ABS(x)					返回x的绝对值
BIN(x)					返回x的二进制（OCT返回八进制，HEX返回十六进制）
CEILING(x) 			 	返回大于x的最小整数值
EXP(x)					返回值e（自然对数的底）的x次方
FLOOR(x)				返回小于x的最大整数值
GREATEST(x1,x2,…,xn)	返回集合中最大的值
LEAST(x1,x2,…,xn)		返回集合中最小的值
LN(x)					返回x的自然对数
LOG(x,y)				返回x的以y为底的对数
MOD(x,y)				返回x/y的模（余数）
PI()					返回pi的值（圆周率）
RAND()					返回０到１内的随机值,可以通过提供一个参数(种子)使							RAND()随机数生成器生成一个指定的值。
ROUND(x,y)				返回参数x的四舍五入的有y位小数的值
SIGN(x)					返回代表数字x的符号的值
SQRT(x)					返回一个数的平方根
TRUNCATE(x,y) 返回数字x截短为y位小数的结果
二、聚合函数(常用于GROUP BY从句的SELECT查询中)
AVG(col)				返回指定列的平均值
COUNT(col)				返回指定列中非NULL值的个数
MIN(col)				返回指定列的最小值
MAX(col)				返回指定列的最大值
SUM(col)				返回指定列的所有值之和
GROUP_CONCAT(col)		返回由属于一组的列值连接组合而成的结果
三、字符串函数
ASCII(char)				返回字符的ASCII码值
BIT_LENGTH(str)			返回字符串的比特长度
CONCAT(s1,s2…,sn)		将s1,s2…,sn连接成字符串
CONCAT_WS(sep,s1,s2…,sn)将s1,s2…,sn连接成字符串，并用sep字符间隔
INSERT(str,x,y,instr)	将字符串str从第x位置开始，y个字符长的子串替换为字符串						 instr，返回结果
FIND_IN_SET(str,list)	分析逗号分隔的list列表，如果发现str，返回str在list中						 的位置
LCASE(str)或LOWER(str)  返回将字符串str中所有字符改变为小写后的结果
LEFT(str,x)				返回字符串str中最左边的x个字符
LENGTH(s)				返回字符串str中的字符数
LTRIM(str)				从字符串str中切掉开头的空格
POSITION(substr,str)	返回子串substr在字符串str中第一次出现的位置
QUOTE(str)　　　　　　　　 用反斜杠转义str中的单引号
REPEAT(str,srchstr,rplcstr)返回字符串str重复x次的结果
REVERSE(str)　　　　　　　 返回颠倒字符串str的结果
RIGHT(str,x)　　　　　　　 返回字符串str中最右边的x个字符
RTRIM(str)　　　　　　　　 返回字符串str尾部的空格
STRCMP(s1,s2)　　　　　　　比较字符串s1和s2
TRIM(str)　　　　　　　　　去除字符串首部和尾部的所有空格
UCASE(str)或UPPER(str)	返回将字符串str中所有字符转变为大写后的结果
四、日期和时间函数
CURDATE()或CURRENT_DATE()返回当前的日期
CURTIME()或CURRENT_TIME()返回当前的时间
DATE_ADD(date,INTERVAL int keyword) 返回日期date加上间隔时间int的结果(int必须按照关键字进行格式化),如：SELECT DATE_ADD(CURRENT_DATE,INTERVAL 6 MONTH);
DATE_FORMAT(date,fmt)	 依照指定的fmt格式格式化日期date值
DATE_SUB(date,INTERVAL int keyword) 返回日期date加上间隔时间int的结果(int必须按照关键字进行格式化),如：SELECT DATE_SUB(CURRENT_DATE,INTERVAL 6 MONTH);
DAYOFWEEK(date)			 返回date所代表的一星期中的第几天(1~7)
DAYOFMONTH(date)		 返回date是一个月的第几天(1~31)
DAYOFYEAR(date)			 返回date是一年的第几天(1~366)
DAYNAME(date)		返回date的星期名，如：SELECT DAYNAME(CURRENT_DATE);
FROM_UNIXTIME(ts,fmt)	 根据指定的fmt格式，格式化UNIX时间戳ts
HOUR(time) 				 返回time的小时值(0~23)
MINUTE(time)			 返回time的分钟值(0~59)
MONTH(date) 			 返回date的月份值(1~12)
MONTHNAME(date) 返回date的月份名，如：SELECT MONTHNAME(CURRENT_DATE);
NOW() 					 返回当前的日期和时间
QUARTER(date) 			 返回date在一年中的季度(1~4)，如SELECT									 QUARTER(CURRENT_DATE);
WEEK(date) 				 返回日期date为一年中第几周(0~53)
YEAR(date) 				 返回日期date的年份(1000~9999)

12.列举 创建索引但是无法命中索引的8种情况。

1、如果条件中有or，即使其中有条件带索引也不会使用(这也是为什么尽量少用or的原因）注意：要想使用or，又想让索引生效，只能将or条件中的每个列都加上索引
2、对于多列索引，不是使用的第一部分(第一个)，则不会使用索引
3、like查询是以%开头
4、如果列类型是字符串，那一定要在条件中将数据使用引号引用起来,否则不使用索引
5、如果mysql估计使用全表扫描要比使用索引快,则不使用索引
其他：

1. 没有查询条件，或者查询条件没有建立索引
2. 在查询条件上没有使用引导列
3. 查询的数量是大表的大部分，应该是30%以上
4. 索引本身失效
5. 查询条件使用函数在索引列上，或者对索引列进行运算，运算包括(+,-,*,/,!等) 错误的例子：select * from test where id-1=9,正确的例子：select * from test where id=10
6. 对小表查询
7. 提示不使用索引
8. 统计数据不真实
9. CBO计算走索引花费过大的情况。其实也包含了上面的情况，这里指的是表占有的block要比索引小
10. 隐式转换导致索引失效，这一点应当引起重视，也是开发中经常会犯的错误。由于表的字段to_mdn定义为varchar(20),但在查询时把该字段作为number类型以where 条件传给Oracle,这样会导致索引失效。错误的例子：select * from test where to_mdn=2333;正确的例子：select * from test where to_mdn=“2333”;
11. 1,<>2,单独的>,<,(有时会用到，有时不会)
12. like “%_” 百分号在前
13. 表没分析
14. 单独引用复合索引里非第一位置的索引列
15. 字符型字段为数字时在where条件里不添加引号
16. 对索引列进行运算，需要建立函数索引。
17. not in , not exist
18. 当变量采用的是times变量，而表的字段采用的是date变量时，或相反情况
19. B-tree索引is null不会走，is not null会走，位图索引 is null , is not null 都会走
20. 联合索引 is not null 只要在建立的索引列(不分先后)都会走，is null时，必须要和建立索引第一列一起使用，当建立索引第一位置条件是is null 时，其他建立索引的列可以是is null(但必须在所有列都满足is null 的时候)，或者=一个值；当建立索引的第一位置是=一个值时，其他索引列可以是任何情况(包括is null =一个值)，以上两种情况索引都会走。其他情况不会走。

13.如何开启慢日志查询？

1、为什么要开启慢日志查询？

开启慢查询日志，可以让MySQL记录下查询超过指定时间的语句，通过定位分析性能的瓶颈，才能更好的优化数据库系统的性能。

2、参数说明

slow_query_log 慢查询开启状态
slow_query_log_file 慢查询日志存放的位置（这个目录需要MySQL的运行帐号的可写权限，一般设置为MySQL的数据存放目录）
long_query_time 查询超过多少秒才记录

3、设置步骤

①.查看慢查询相关参数

mysql> show variables like 'slow_query%';
+---------------------------+----------------------------------+
| Variable_name             | Value                            |
+---------------------------+----------------------------------+
| slow_query_log            | OFF                              |
| slow_query_log_file       | /mysql/data/localhost-slow.log   |
+---------------------------+----------------------------------+

mysql> show variables like 'long_query_time';
+-----------------+-----------+
| Variable_name   | Value     |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+

②.设置方法

将 slow_query_log 全局变量设置为“ON”状态

mysql> set global slow_query_log='ON';

设置慢查询日志存放的位置

mysql> set global slow_query_log_file='/var/lib/mysql/test-10-226-slow.log';

查询超过1秒就记录

mysql> set global long_query_time=1;

经过这些操作，则慢日志查询也就开启了！但这种方法只是临时生效，mysql重启后就会失效

所以我们不能让他失效，所以需进行如下操作

编辑配置文件/etc/my.cnf加入如下内容

[mysqld]
slow_query_log = ON
slow_query_log_file = /var/lib/mysql/test-10-226-slow.log
long_query_time = 1

使用下面命令验证

show variables like 'slow_query%';

mysql永久开启了慢查询日志功能

14.数据库导入导出命令（结构+数据）？

window下

• 导出整个数据库
  mysqldump -u 用户名 -p 数据库名 > 导出的文件名

  mysqldump -u username -p dbname > dbname.sql
  

• 导出一个表，包括表结构和数据
  mysqldump -u 用户名 -p 数据库名 表名 > 导出的文件名

  mysqldump -u username -p dbname tablename > dbname_tablename.sql
  

• 导出一个数据库结构
  mysqldump -u username -p -d --add-drop-table dbname > d:/dbname_db.sql
  -d 忽略数据
  –add-drop-table 在每个create语句之前增加一个drop table

• 导出一个表，只有表结构

  mysqldump -u用户名 -p 密码 -d数据库名 表名> 导出的文件名

  mysqldump -uroot -pmysql -d sva_rec date_rec_drv> e:\date_rec_drv.sql

• 导入数据库
  常用source 命令
  进入mysql数据库控制台，如：

  mysql -u root -p
  mysql>use dbname;
  

  然后使用source命令，后面参数为脚本文件

  mysql> source d:/dbname.sql;
  

linux下

• 导出数据和表结构：
  mysqldump -u 用户名 -p 数据库名 > 数据库名.sql

• 只导出表结构
  mysqldump -u 用户名 -p -d 数据库名 > 数据库名.sql

• 导入数据库，需要首先建空数据库

  mysql>create database abc;
  

• 导入数据库方法一：

  • 选择数据库

    mysql>use abc;
    

  • 设置数据库编码

    mysql>set names utf8;
    

  • 导入数据（注意sql文件的路径）

    mysql>source /home/abc/abc.sql;
    

• 导入数据库方法二：

  mysql -u 用户名 -p 数据库名 < 数据库名.sql

15.数据库优化方案？

• 硬件优化

• 定位慢SQL，并优化

• 合理使用索引

• 分表 水平分割（按行）、垂直分割(按列)

• 读写分离 使用负载均衡实现，写操作都往主库上写，读操作往从服务器上读

• 缓存 短时间内相同数据重复查询多次且数据更新不频繁

  https://blog.csdn.net/u013628152/article/details/82184809

16.char和varchar的区别？

char类型：定长不可变

存入字符长度大于设置长度时，会报错；存入字符长度小于设置长度时，用空格填充剩余长度，浪费空间，但是存取速度快。

varchar类型：可变

不使用空格填充，在真实数据前加1-2Bytes作前缀，用来表示真实数据的字节数，节省空间，存取速度较慢。
sql优化：创建表时，定长的类型往前放，变长的往后放

17.简述MySQL的执行计划？

MySQL数据库中，在SELECT查询语句前边加上“EXPLAIN”或者“DESC”关键字，即可查看该查询语句的执行计划，分析执行计划是优化慢查询的重要手段。

具体的Mysql的执行计划，请参考下面的链接：

MySQL_执行计划详细说明

18.在对name做了唯一索引前提下，简述以下区别：

select * from tb where name = ‘Oldboy-Wupeiqi’ 

select * from tb where name = ‘Oldboy-Wupeiqi’ limit 1

当只有一行数据时使用 LIMIT 1，在这种情况下，加上 LIMIT 1 可以增加性能。这样一样，MySQL数据库引擎会在找到一条数据后停止搜索，而不是继续往后查少下一条符合记录的数据。

19.1000w条数据，使用limit offffset 分页时，为什么越往后翻越慢？如何解决？

因为页数越大，mysql要扫描的行数越多
解决： 提供线索
如果 LIMIT m,n 不可避免的话，要优化效率，只有尽可能的让m小一下，我们扩展前面的”clue”做法，还是SELECT * FROM message ORDER BY id DESC，按id降序分页，每页20条，当前是第10页，当前页条目id最大的是9527，最小的是9500,比如要跳到第8页，
SQL语句可以这 样写：

SELECT * FROM message WHERE id > 9527 ORDER BY id ASC LIMIT 20,20;

跳转到第13页：

SELECT * FROM message WHERE id < 9500 ORDER BY id DESC LIMIT 40,20;

原理还是一样，记录住当前页id的最大值和最小值，计算跳转页面和当前页相对偏移，由于页面相近，这个偏移量不会很大，这样的话m值相对较小，大大 减少扫描的行数。其实传统的limit m,n，相对的偏移一直是第一页，这样的话越翻到后面，效率越差，而上面给出的方法就没有这样的问题。
https://blog.csdn.net/helloxiaozhe/article/details/78106709

20.什么是索引合并？

1. 索引合并是把几个索引的范围扫描合并成一个索引。

2. 索引合并的时候，会对索引进行并集，交集或者先交集再并集操作，以便合并成一个索引。

3. 这些需要合并的索引只能是一个表的。不能对多表进行索引合并。

21.什么是覆盖索引？

通常开发人员会根据查询的where条件来创建合适的索引，但是优秀的索引设计应该考虑到整个查询。其实mysql可以使用索引来直接获取列的数据。如果索引的叶子节点包含了要查询的数据，那么就不用回表查询了，也就是说这种索引包含（亦称覆盖）所有需要查询的字段的值，我们称这种索引为覆盖索引。

回想一下，如果查询只需要扫描索引而无须回表，将带来诸多好处。

（1）索引条目通常远小于数据行大小，如果只读取索引，MySQL就会极大地减少数据访问量。

（2）索引按照列值顺序存储，对于I/O密集的范围查询会比随机从磁盘中读取每一行数据的I/O要少很多。

（3）InnoDB的辅助索引（亦称二级索引）在叶子节点中保存了行的主键值，如果二级索引能够覆盖查询，则可不必对主键索引进行二次查询了。

覆盖索引就是从索引中直接获取查询结果，要使用覆盖索引需要注意select查询列中包含在索引列中；where条件包含索引列或者复合索引的前导列；查询结果的字段长度尽可能少。

辅助索引中就可以得到查询记录，而不需要查询聚集索引中的记录。通常需要建立联合索引。
使用覆盖索引的一个好处是：辅助索引不包含整行记录的所有信息，故其大小要远小于聚集索引，因此可以减少大量的IO操作

22.简述数据库读写分离？

MySQL Proxy最强大的一项功能是实现“读写分离(Read/Write Splitting)”。基本的原理是让主数据库处理事务性查询，而从数据库处理SELECT查询。数据库复制被用来把事务性查询导致的变更同步到集群中的从数据库。 当然，主服务器也可以提供查询服务。使用读写分离最大的作用无非是缓解服务器压力。可以看下这张图：

读写分离的好处

1. 增加冗余

2. 增加了机器的处理能力

3. 对于读操作为主的应用，使用读写分离是最好的场景，因为可以确保写的服务器压力更小，而读又可以接受点时间上的延迟。

读写分离提高性能之原因

1. 物理服务器增加，负荷增加

2. 主从只负责各自的写和读，极大程度的缓解X锁和S锁争用

3. 从库可配置myisam引擎，提升查询性能以及节约系统开销

4. 从库同步主库的数据和主库直接写还是有区别的,通过主库发送来的binlog恢复数据，但是，最重要区别在于主库向从库发送binlog是异步的，从库恢复数据也是异步的

5. 读写分离适用与读远大于写的场景，如果只有一台服务器，当select很多时，update和delete会被这些select访问中的数据堵塞，等待select结束，并发性能不高。 对于写和读比例相近的应用，应该部署双主相互复制

6. 可以在从库启动是增加一些参数来提高其读的性能，例如–skip-innodb、–skip-bdb、–low-priority-updates以及–delay-key-write=ALL。当然这些设置也是需要根据具体业务需求来定得，不一定能用上

7. 分摊读取。假如我们有1主3从，不考虑上述1中提到的从库单方面设置，假设现在1分钟内有10条写入，150条读取。那么，1主3从相当于共计40条写入，而读取总数没变，因此平均下来每台服务器承担了10条写入和50条读取（主库不承担读取操作）。因此，虽然写入没变，但是读取大大分摊了，提高了系统性能。另外，当读取被分摊后，又间接提高了写入的性能。所以，总体性能提高了，说白了就是拿机器和带宽换性能。MySQL官方文档中有相关演算公式：官方文档 见6.9FAQ之“MySQL复制能够何时和多大程度提高系统性能”

8. MySQL复制另外一大功能是增加冗余，提高可用性，当一台数据库服务器宕机后能通过调整另外一台从库来以最快的速度恢复服务，因此不能光看性能，也就是说1主1从也是可以的。

读写分离示意图

23.简述数据库分库分表？（水平、垂直）

（1）数据库分表

把一张表按照一定的规则分解成不同的实体表。比如垂直划分和水平划分

垂直切分：把不同功能，不同模块的数据分别放到不同的表中，但是如果同一个模块的数据量太大就会存在性能瓶颈,垂直切分可以使模块的划分更清晰，分成功能不同的表

水平切分：垂直切分解决不了大表的瓶颈，如果同一个功能中表的数据量过大，就要对该表进行切分，为水平切分。水平切分可以解决大数据下大表性能的瓶颈问题。

通俗理解：垂直切分—分不同的模块表；水平切分—分同一个模块下的多个表

（2）分库

将一堆数据放到不同的数据库中保存，上面说的都是在同一个数据库上，分库是分到不同的数据库上

请参考链接https://www.cnblogs.com/butterfly100/p/9034281.html

24.redis和memcached比较？

我个人认为最本质的不同是Redis在很多方面具备数据库的特征，或者说就是一个内存数据库系统，而Memcached只是简单的K/V缓存，mongodb本质上是一个物理数据库。

区别：

1. 性能（网络IO模型）
   Memcached是多线程，非阻塞IO复用的网络模型。Memcache可以利用多核优势，单实例吞吐量极高，可以达到几十万QPS,适用于最大程度扛量。
   Redis使用单线程的IO复用模型。由于Redis只使用单核，而Memcached可以使用多核，所以在比较上，平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中，Memcached性能要高于Redis，虽然Redis最近也在存储大数据的性能上进行优化，但是比起Memcached，还是稍有逊色。

2. 内存使用
   MemCached可以修改最大内存，采用LRU算法。Redis增加了VM的特性，突破了物理内存的限制。
   使用简单的key-value存储的话，Memcached的内存利用率更高，而如果Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于Memcache。
   Memcached使用预分配的内存池的方式，使用slab和大小不同的chunk来管理内存，Item根据大小选择合适的chunk存储，内存池的方式可以省去申请/释放内存的开销，并且能减小内存碎片产生，但这种方式也会带来一定程度上的空间浪费，并且在内存仍然有很大空间时，新的数据也可能会被剔除，原因可以参考Timyang的文章：http://timyang.net/data/Memcached-lru-evictions/
   Redis使用现场申请内存的方式来存储数据，并且很少使用free-list等方式来优化内存分配，会在一定程度上存在内存碎片，Redis跟据存储命令参数，会把带过期时间的数据单独存放在一起，并把它们称为临时数据，非临时数据是永远不会被剔除的，即便物理内存不够，导致swap也不会剔除任何非临时数据（但会尝试剔除部分临时数据），这点上Redis更适合作为存储而不是cache。

3. 数据一致性
   Memcached提供了cas命令，可以保证多个并发访问操作同一份数据的一致性问题。CAS（Check and Set）是一个确保并发一致性的机制，属于“乐观锁”范畴；原理很简单：拿版本号，操作，对比版本号，如果一致就操作，不一致就放弃任何操作。
   redis使用的是单线程模型，提供了事务的功能，可以保证一串 命令的原子性，中间不会被任何操作打断，保证了数据按顺序提交。

4. 可靠性
   memecache 把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小。
   redis有部份存在硬盘上，这样能保证数据的持久性，支持数据的持久化。

5. 数据备份
   Redis支持数据的备份，即master-slave主从复制。

6. 分布式存储
   redis支持master-slave复制模式
   memcache可以使用一致性hash做分布式

7. 数据支持类型
   Memcached基本只支持简单的key-value存储，不过memcache还可用于缓存其他东西，例如图片、视频等等。
   Redis除key/value之外，还支持list,set,sorted set,hash等众多数据结构。也可以在服务器端直接对数据进行丰富的操作,这样可以减少网络IO次数和数据体积。

8. 应用场景：
   Memcached：动态系统中减轻数据库负载，提升性能；做缓存，适合多读少写，大数据量的情况（如人人网大量查询用户信息、好友信息、文章信息等）。
   Redis：适用于对读写效率要求都很高，数据处理业务复杂和对安全性要求较高的系统（如新浪微博的计数和微博发布部分系统，对数据安全性、读写要求都很高）。

9. 关于不同语言的客户端支持
   在不同语言的客户端方面，Memcached和Redis都有丰富的第三方客户端可供选择，不过因为Memcached发展的时间更久一些，目前看在客户端支持方面，Memcached的很多客户端更加成熟稳定，而Redis由于其协议本身就比Memcached复杂，加上作者不断增加新的功能等，对应第三方客户端跟进速度可能会赶不上，有时可能需要自己在第三方客户端基础上做些修改才能更好的使用。

10. 应用举例
    memcache：Memcached 是一个高性能的分布式内存对象缓存系统，用于动态Web应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提供动态、数据库驱动网站的速度，现在已被LiveJournal、hatena、Facebook、Vox、LiveJournal等公司所使用。
    redis：国内像新浪、淘宝，国外像 Flickr、Github等均在使用Redis的缓存服务。

    对于两者的选择还是要看具体的应用场景，如果需要缓存的数据只是key-value这样简单的结构时，我在项目里还是采用memcache，它也足够的稳定可靠。如果涉及到存储，排序等一系列复杂的操作时，毫无疑问选择redis。
    有持久化需求或者对数据结构和处理有高级要求的应用，只能选择redis，其他简单的key/value存储，选择memcache。

应该说Memcached和Redis都能很好的满足解决我们的问题，它们性能都很高，总的来说，可以把Redis理解为是对Memcached的拓展，是更加重量级的实现，提供了更多更强大的功能。

需要慎重考虑的部分

1.Memcached单个key-value大小有限，一个value最大只支持1MB，而Redis最大支持512MB
2.Memcached只是个内存缓存，对可靠性无要求；而Redis更倾向于内存数据库，因此对对可靠性方面要求比较高
3.从本质上讲，Memcached只是一个单一key-value内存Cache；而Redis则是一个数据结构内存数据库，支持五种数据类型，因此Redis除单纯缓存作用外，还可以处理一些简单的逻辑运算，Redis不仅可以缓存，而且还可以作为数据库用
4.新版本（3.0）的Redis是指集群分布式，也就是说集群本身均衡客户端请求，各个节点可以交流，可拓展行、可维护性更强大。

参考链接：
https://blog.csdn.net/chaoluo001/article/details/70740307
https://www.cnblogs.com/EE-NovRain/p/3268476.html
https://blog.csdn.net/hhjianlong/article/details/73928653
https://www.cnblogs.com/haoyu521/p/5608309.html
https://www.cnblogs.com/JavaBlackHole/p/7726195.html

25.redis中数据库默认是多少个db 及作用？

redis默认有16个db，db0~db15（可以通过配置文件支持更多，无上限）
并且每个数据库的数据是隔离的不能共享
可以随时使用SELECT命令更换数据库：redis> SELECT 1

注意：

多个数据库之间并不是完全隔离的
比如FLUSHALL命令可以清空一个Redis实例中所有数据库中的数据。

26.python操作redis的模块？

什么是redis？

redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。

上面的话好像很专业的样子，这里我们简单的理解为，其实redis就是一个消息中间件，可以作为多个进程的消息中转站，是比之前我们用的manage模块更方便自由的共享内存。

1、基本操作

之前我们已经知道，redis是以key-value的形式存储的，所以我们在操作的时候。首先我们将redis所在主机的ip和发布端口作为参数实例化了一个对象r，然后执行set(‘name’,‘Eva_J’)，这样我们就在内存中存储了一个key为name，值为‘Eva_J’的项。我们可以理解为{‘name’:‘Eva_J’},当我们要读取的之后，只需要get(‘name’)，就会得到’Eva_J’的值。

2、连接池

redis-py使用connection pool来管理对一个redis server的所有连接，避免每次建立、释放连接的开销。默认，每个Redis实例都会维护一个自己的连接池。可以直接建立一个连接池，然后作为参数Redis，这样就可以实现多个Redis实例共享一个连接池。

3、管道

redis-py默认在执行每次请求都会创建（连接池申请连接）和断开（归还连接池）一次连接操作，如果想要在一次请求中指定多个命令，则可以使用pipline实现一次请求指定多个命令，并且默认情况下一次pipline 是原子性操作。

请参考链接：https://www.cnblogs.com/xtsec/p/7000404.html

27.如果redis中的某个列表中的数据量非常大，如果实现循环显示每一个值？

# 通过scan_iter分片取，减少内存压力
scan_iter(match=None, count=None)   # 增量式迭代获取redis里匹配的的值
# match，匹配指定key
# count，每次分片最少获取个数
r = redis.Redis(connection_pool=pool)
for key in r.scan_iter(match='PREFIX_*', count=100000):
    print(key)

28.redis如何实现主从复制？以及数据同步机制？

实现主从复制：

‘创建6379和6380配置文件’
redis.conf：6379为默认配置文件，作为Master服务配置；
redis_6380.conf：6380为同步配置，作为Slave服务配置；
‘配置slaveof同步指令’
在Slave对应的conf配置文件中，添加以下内容：
slaveof 127.0.0.1 6379

数据同步步骤：

(1)Slave服务器连接到Master服务器.
(2)Slave服务器发送同步(SYCN)命令.
(3)Master服务器备份数据库到文件.
(4)Master服务器把备份文件传输给Slave服务器.
(5)Slave服务器把备份文件数据导入到数据库中.

请参考链接：https://www.cnblogs.com/kevingrace/p/5685332.html

29.redis中的sentinel的作用？

redis中的sentinel的作用?

Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换。

它的主要功能有以下几点：

不时地监控redis是否按照预期良好地运行;

如果发现某个redis节点运行出现状况，能够通知另外一个进程(例如它的客户端);

能够进行自动切换。当一个master节点不可用时，能够选举出master的多个slave(如果有超过一个slave的话)中的一个来作为新的master,其它的slave节点会将它所追随的master的地址改为被提升为master的slave的新地址。

请参考链接：https://segmentfault.com/a/1190000002680804

参考链接：https://segmentfault.com/a/1190000002685515

30.如何实现redis集群？

由于Redis出众的性能，其在众多的移动互联网企业中得到广泛的应用。Redis在3.0版本前只支持单实例模式，虽然现在的服务器内存可以到100GB、200GB的规模，但是单实例模式限制了Redis没法满足业务的需求（例如新浪微博就曾经用Redis存储了超过1TB的数据）。Redis的开发者Antirez早在博客上就提出在Redis 3.0版本中加入集群的功能，但3.0版本等到2015年才发布正式版。各大企业在3.0版本还没发布前为了解决Redis的存储瓶颈，纷纷推出了各自的Redis集群方案。这些方案的核心思想是把数据分片（sharding）存储在多个Redis实例中，每一片就是一个Redis实例。

下面介绍Redis的集群方案。

1、客户端分片

客户端分片是把分片的逻辑放在Redis客户端实现，通过Redis客户端预先定义好的路由规则，把对Key的访问转发到不同的Redis实例中，最后把返回结果汇集。这种方案的模式如下图所示。

客户端分片的好处是所有的逻辑都是可控的，不依赖于第三方分布式中间件。开发人员清楚怎么实现分片、路由的规则，不用担心踩坑。

客户端分片方案有下面这些缺点：

●这是一种静态的分片方案，需要增加或者减少Redis实例的数量，需要手工调整分片的程序。

●可运维性差，集群的数据出了任何问题都需要运维人员和开发人员一起合作，减缓了解决问题的速度，增加了跨部门沟通的成本。

●在不同的客户端程序中，维护相同的分片逻辑成本巨大。例如，系统中有两套业务系统共用一套Redis集群，一套业务系统用Java实现，另一套业务系统用PHP实现。为了保证分片逻辑的一致性，在Java客户端中实现的分片逻辑也需要在PHP客户端实现一次。相同的逻辑在不同的系统中分别实现，这种设计本来就非常糟糕，而且需要耗费巨大的开发成本保证两套业务系统分片逻辑的一致性。

2、Twemproxy

Twemproxy是由Twitter开源的Redis代理，其基本原理是：Redis客户端把请求发送到Twemproxy，Twemproxy根据路由规则发送到正确的Redis实例，最后Twemproxy把结果汇集返回给客户端。

Twemproxy通过引入一个代理层，将多个Redis实例进行统一管理，使Redis客户端只需要在Twemproxy上进行操作，而不需要关心后面有多少个Redis实例，从而实现了Redis集群。

Twemproxy集群架构如下图所示：

Twemproxy的优点如下：

●客户端像连接Redis实例一样连接Twemproxy，不需要改任何的代码逻辑。

●支持无效Redis实例的自动删除。

●Twemproxy与Redis实例保持连接，减少了客户端与Redis实例的连接数。

Twemproxy的缺点如下：

●由于Redis客户端的每个请求都经过Twemproxy代理才能到达Redis服务器，这个过程中会产生性能损失。

●没有友好的监控管理后台界面，不利于运维监控。

●最大的问题是Twemproxy无法平滑地增加Redis实例。对于运维人员来说，当因为业务需要增加Redis实例时工作量非常大。

Twemproxy作为最被广泛使用、最久经考验、稳定性最高的Redis代理，在业界被广泛使用。

3、Redis 3.0集群

Redis 3.0集群采用了P2P的模式，完全去中心化。Redis把所有的Key分成了16384个slot，每个Redis实例负责其中一部分slot。集群中的所有信息（节点、端口、slot等），都通过节点之间定期的数据交换而更新。

Redis客户端在任意一个Redis实例发出请求，如果所需数据不在该实例中，通过重定向命令引导客户端访问所需的实例。

Redis 3.0集群的工作流程如下图所示：

如图所示Redis集群内的机器定期交换数据，工作流程如下：

（1） Redis客户端在Redis2实例上访问某个数据。

（2） 在Redis2内发现这个数据是在Redis3这个实例中，给Redis客户端发送一个重定向的命令。

（3） Redis客户端收到重定向命令后，访问Redis3实例获取所需的数据。

Redis 3.0的集群方案有以下两个问题：

●一个Redis实例具备了“数据存储”和“路由重定向”，完全去中心化的设计。这带来的好处是部署非常简单，直接部署Redis就行，不像Codis有那么多的组件和依赖。但带来的问题是很难对业务进行无痛的升级，如果哪天Redis集群出了什么严重的Bug，就只能回滚整个Redis集群。

●对协议进行了较大的修改，对应的Redis客户端也需要升级。升级Redis客户端后谁能确保没有Bug？而且对于线上已经大规模运行的业务，升级代码中的Redis客户端也是一个很麻烦的事情。

综合上面所述的两个问题，Redis 3.0集群在业界并没有被大规模使用。

4、云服务器上的集群服务

国内的云服务器提供商阿里云、UCloud等均推出了基于Redis的云存储服务。

这个服务的特性如下。

（1）动态扩容

用户可以通过控制面板升级所需的Redis存储空间，扩容的过程中服务部不需要中断或停止，整个扩容过程对用户透明、无感知，这点是非常实用的，在前面介绍的方案中，解决Redis平滑扩容是个很烦琐的任务，现在按几下鼠标就能搞定，大大减少了运维的负担。

（2）数据多备

数据保存在一主一备两台机器中，其中一台机器宕机了，数据还在另外一台机器上有备份。

（3）自动容灾

主机宕机后系统能自动检测并切换到备机上，实现服务的高可用。

（4）实惠

很多情况下为了使Redis的性能更高，需要购买一台专门的服务器用于Redis的存储服务，但这样子CPU、内存等资源就浪费了，购买Redis云存储服务就很好地解决了这个问题。

有了Redis云存储服务，能使App后台开发人员从烦琐运维中解放出来。App后台要搭建一个高可用、高性能的Redis服务，需要投入相当的运维成本和精力。如果使用云存储服务，就没必要投入这些成本和精力，可以让App后台开发人员更专注于业务。

31.redis中默认有多少个哈希槽？

Redis 集群中内置了 16384 个哈希槽，当需要在 Redis 集群中放置一个 key-value时，redis 先对 key 使用 crc16 算法算出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，redis 会根据节点数量大致均等的将哈希槽映射到不同的节点。

Redis 集群没有使用一致性hash, 而是引入了哈希槽的概念。

Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个节点负责一部分hash槽。这种结构很容易添加或者删除节点，并且无论是添加删除或者修改某一个节点，都不会造成集群不可用的状态。

使用哈希槽的好处就在于可以方便的添加或移除节点。

当需要增加节点时，只需要把其他节点的某些哈希槽挪到新节点就可以了；

当需要移除节点时，只需要把移除节点上的哈希槽挪到其他节点就行了；

在这一点上，我们以后新增或移除节点的时候不用先停掉所有的 redis 服务。

"用了哈希槽的概念，而没有用一致性哈希算法，不都是哈希么？这样做的原因是为什么呢？"
Redis Cluster是自己做的crc16的简单hash算法，没有用一致性hash。Redis的作者认为它的crc16(key) mod 16384的效果已经不错了，虽然没有一致性hash灵活，但实现很简单，节点增删时处理起来也很方便。

"为了动态增删节点的时候，不至于丢失数据么？"
节点增删时不丢失数据和hash算法没什么关系，不丢失数据要求的是一份数据有多个副本。

“还有集群总共有2的14次方，16384个哈希槽，那么每一个哈希槽中存的key 和 value是什么？”
当你往Redis Cluster中加入一个Key时，会根据crc16(key) mod 16384计算这个key应该分布到哪个hash slot中，一个hash slot中会有很多key和value。你可以理解成表的分区，使用单节点时的redis时只有一个表，所有的key都放在这个表里；改用Redis Cluster以后会自动为你生成16384个分区表，你insert数据时会根据上面的简单算法来决定你的key应该存在哪个分区，每个分区里有很多key。

32.简述redis的有哪几种持久化策略及比较？

Redis 提供了多种不同级别的持久化方式：

RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照(point-in-time snapshot)。

AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写(rewrite)，使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。

Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。

你甚至可以关闭持久化功能，让数据只在服务器运行时存在。

RDB知识点

RDB 的优点

RDB 是一个非常紧凑(compact)的文件，它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份： 比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。 这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。

RDB 非常适用于灾难恢复(disaster recovery)：它只有一个文件，并且内容都非常紧凑，可以(在加密后)将它传送到别的数据中心，或者亚马逊 S3 中。

RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。

RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

RDB 的缺点

如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。 虽然 Redis 允许你设置不同的保存点(save point)来控制保存 RDB 文件的频率， 但是， 因为RDB 文件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据。

每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端; 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。

AOF知识点

AOF 的优点

使用 AOF 持久化会让 Redis 变得非常耐久(much more durable)：你可以设置不同的 fsync 策略，比如无 fsync ，每秒钟一次 fsync ，或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据( fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求)。

AOF 文件是一个只进行追加操作的日志文件(append only log)， 因此对 AOF 文件的写入不需要进行 seek ， 即使日志因为某些原因而包含了未写入完整的命令(比如写入时磁盘已满，写入中途停机，等等)， redis-check-aof 工具也可以轻易地修复这种问题。

Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。

AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析(parse)也很轻松。 导出(export) AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

AOF 的缺点

对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。

根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间(latency)。

AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。 (举个例子，阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug 。) 测试套件里为这种情况添加了测试： 它们会自动生成随机的、复杂的数据集， 并通过重新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中并不常见， 但是对比来说， RDB 几乎是不可能出现这种 bug 的。

33.列举redis支持的过期策略。

Redis key过期的方式有三种：

• 被动删除：当读/写一个已经过期的key时，会触发惰性删除策略，直接删除掉这个过期key
• 主动删除：由于惰性删除策略无法保证冷数据被及时删掉，所以Redis会定期主动淘汰一批已过期的key
• 当前已用内存超过maxmemory限定时，触发主动清理策略

被动删除

只有key被操作时(如GET)，REDIS才会被动检查该key是否过期，如果过期则删除之并且返回NIL。

1、这种删除策略对CPU是友好的，删除操作只有在不得不的情况下才会进行，不会其他的expire key上浪费无谓的CPU时间。

2、但是这种策略对内存不友好，一个key已经过期，但是在它被操作之前不会被删除，仍然占据内存空间。如果有大量的过期键存在但是又很少被访问到，那会造成大量的内存空间浪费。expireIfNeeded(redisDb *db, robj *key)函数位于src/db.c。但仅是这样是不够的，因为可能存在一些key永远不会被再次访问到，这些设置了过期时间的key也是需要在过期后被删除的，我们甚至可以将这种情况看作是一种内存泄露----无用的垃圾数据占用了大量的内存，而服务器却不会自己去释放它们，这对于运行状态非常依赖于内存的Redis服务器来说，肯定不是一个好消息

主动删除

先说一下时间事件，对于持续运行的服务器来说， 服务器需要定期对自身的资源和状态进行必要的检查和整理， 从而让服务器维持在一个健康稳定的状态， 这类操作被统称为常规操作（cron job）

在 Redis 中， 常规操作由 redis.c/serverCron 实现， 它主要执行以下操作

• 更新服务器的各类统计信息，比如时间、内存占用、数据库占用情况等。
• 清理数据库中的过期键值对。
• 对不合理的数据库进行大小调整。
• 关闭和清理连接失效的客户端。
• 尝试进行 AOF 或 RDB 持久化操作。
• 如果服务器是主节点的话，对附属节点进行定期同步。
• 如果处于集群模式的话，对集群进行定期同步和连接测试。

Redis 将 serverCron 作为时间事件来运行， 从而确保它每隔一段时间就会自动运行一次， 又因为 serverCron 需要在 Redis 服务器运行期间一直定期运行， 所以它是一个循环时间事件： serverCron 会一直定期执行，直到服务器关闭为止。

在 Redis 2.6 版本中， 程序规定 serverCron 每秒运行 10 次， 平均每 100 毫秒运行一次。 从 Redis 2.8 开始， 用户可以通过修改 hz选项来调整 serverCron 的每秒执行次数， 具体信息请参考 redis.conf 文件中关于 hz 选项的说明

也叫定时删除，这里的“定期”指的是Redis定期触发的清理策略，由位于src/redis.c的activeExpireCycle(void)函数来完成。

serverCron是由redis的事件框架驱动的定位任务，这个定时任务中会调用activeExpireCycle函数，针对每个db在限制的时间REDIS_EXPIRELOOKUPS_TIME_LIMIT内迟可能多的删除过期key，之所以要限制时间是为了防止过长时间 的阻塞影响redis的正常运行。这种主动删除策略弥补了被动删除策略在内存上的不友好。

因此，Redis会周期性的随机测试一批设置了过期时间的key并进行处理。测试到的已过期的key将被删除。典型的方式为,Redis每秒做10次如下的步骤：

• 随机测试100个设置了过期时间的key
• 删除所有发现的已过期的key
• 若删除的key超过25个则重复步骤1

这是一个基于概率的简单算法，基本的假设是抽出的样本能够代表整个key空间，redis持续清理过期的数据直至将要过期的key的百分比降到了25%以下。这也意味着在任何给定的时刻已经过期但仍占据着内存空间的key的量最多为每秒的写操作量除以4.

Redis-3.0.0中的默认值是10，代表每秒钟调用10次后台任务。

除了主动淘汰的频率外，Redis对每次淘汰任务执行的最大时长也有一个限定，这样保证了每次主动淘汰不会过多阻塞应用请求，以下是这个限定计算公式：

#define ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC 25 /* CPU max % for keys collection */ 
... 
timelimit = 1000000*ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC/server.hz/100;

hz调大将会提高Redis主动淘汰的频率，如果你的Redis存储中包含很多冷数据占用内存过大的话，可以考虑将这个值调大，但Redis作者建议这个值不要超过100。我们实际线上将这个值调大到100，观察到CPU会增加2%左右，但对冷数据的内存释放速度确实有明显的提高（通过观察keyspace个数和used_memory大小）。

可以看出timelimit和server.hz是一个倒数的关系，也就是说hz配置越大，timelimit就越小。换句话说是每秒钟期望的主动淘汰频率越高，则每次淘汰最长占用时间就越短。这里每秒钟的最长淘汰占用时间是固定的250ms（1000000*ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC/100），而淘汰频率和每次淘汰的最长时间是通过hz参数控制的。

从以上的分析看，当redis中的过期key比率没有超过25%之前，提高hz可以明显提高扫描key的最小个数。假设hz为10，则一秒内最少扫描200个key（一秒调用10次*每次最少随机取出20个key），如果hz改为100，则一秒内最少扫描2000个key；另一方面，如果过期key比率超过25%，则扫描key的个数无上限，但是cpu时间每秒钟最多占用250ms。

当REDIS运行在主从模式时，只有主结点才会执行上述这两种过期删除策略，然后把删除操作”del key”同步到从结点。

maxmemory

当前已用内存超过maxmemory限定时，触发主动清理策略

• volatile-lru：只对设置了过期时间的key进行LRU（默认值）
• allkeys-lru ： 删除lru算法的key
• volatile-random：随机删除即将过期key
• allkeys-random：随机删除
• volatile-ttl ： 删除即将过期的
• noeviction ： 永不过期，返回错误当mem_used内存已经超过maxmemory的设定，对于所有的读写请求，都会触发redis.c/freeMemoryIfNeeded(void)函数以清理超出的内存。注意这个清理过程是阻塞的，直到清理出足够的内存空间。所以如果在达到maxmemory并且调用方还在不断写入的情况下，可能会反复触发主动清理策略，导致请求会有一定的延迟。

当mem_used内存已经超过maxmemory的设定，对于所有的读写请求，都会触发redis.c/freeMemoryIfNeeded(void)函数以清理超出的内存。注意这个清理过程是阻塞的，直到清理出足够的内存空间。所以如果在达到maxmemory并且调用方还在不断写入的情况下，可能会反复触发主动清理策略，导致请求会有一定的延迟。

清理时会根据用户配置的maxmemory-policy来做适当的清理（一般是LRU或TTL），这里的LRU或TTL策略并不是针对redis的所有key，而是以配置文件中的maxmemory-samples个key作为样本池进行抽样清理。

maxmemory-samples在redis-3.0.0中的默认配置为5，如果增加，会提高LRU或TTL的精准度，redis作者测试的结果是当这个配置为10时已经非常接近全量LRU的精准度了，并且增加maxmemory-samples会导致在主动清理时消耗更多的CPU时间，建议：

• 尽量不要触发maxmemory，最好在mem_used内存占用达到maxmemory的一定比例后，需要考虑调大hz以加快淘汰，或者进行集群扩容。
• 如果能够控制住内存，则可以不用修改maxmemory-samples配置；如果Redis本身就作为LRU cache服务（这种服务一般长时间处于maxmemory状态，由Redis自动做LRU淘汰），可以适当调大maxmemory-samples。

Replication link和AOF文件中的过期处理

为了获得正确的行为而不至于导致一致性问题，当一个key过期时DEL操作将被记录在AOF文件并传递到所有相关的slave。也即过期删除操作统一在master实例中进行并向下传递，而不是各salve各自掌控。这样一来便不会出现数据不一致的情形。当slave连接到master后并不能立即清理已过期的key（需要等待由master传递过来的DEL操作），slave仍需对数据集中的过期状态进行管理维护以便于在slave被提升为master会能像master一样独立的进行过期处理。

34.MySQL 里有 2000w 数据,redis 中只存 20w 的数据,如何保证 redis 中都是热点数据？

redis 内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。redis 提供 6种数据淘汰策略：

volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰

volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰

volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰

allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰

allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰

no-enviction（驱逐）：禁止驱逐数据

35.写代码，基于redis的列表实现 先进先出、后进先出队列、优先级队列。

先进lpush keys values 先出 rpop keys

先进lpush keys values 后出 lpop keys

36.如何基于redis实现消息队列？

Redis中五大数据结构之一—列表，其PUSH和POP命令遵循FIFO先进先出原则。当我们需要发布消息的时候执行LPUSH(消息从左边进入队列)，消息接收端执行RPOP获得消息(消息从右侧弹出)。对于列表，Redis提供了带有阻塞的命令(命令前加B)。因此，生产者lpush消息，消费者brpop(从列表中弹出最右端元素，如无元素则一直阻塞到timeout)消息，并设定超时时间timeout，可以减少redis的压力。

37.如何基于redis实现发布和订阅？以及发布订阅和消息队列的区别？

“发布/订阅”模式包含两种角色，分别是发布者和订阅者。订阅者可以订阅一个或若干个频道（channel），而发布者可以向指定的频道发送消息，所有订阅此频道的订阅者都会收到此消息。

38.什么是codis及作用？

Codis是一个分布式的Redis解决方案，对于上层的应用来说，连接Codis Proxy和连接原生的Redis Server没有明显的区别，上层应用可以像使用单机的Redis一样使用，Codis底层会处理请求的转发，不停机的数据迁移等工作，所有后边的一切事情，对于前面客户端来说是透明的，可以简单的认为后边连接是一个内存无限大的Redis服务。

业务需要，数据可能需要迁移，机器横向扩容

经过线上测试，Codis的升级版Reborn在pipline操作的性能比Codis慢了几十倍

请参考链接：https://blog.csdn.net/ymeng9527/article/details/99658061

39.什么是twemproxy及作用？

Twemproxy是一种代理分片机制，是 Twtter 开源的一个 Redis 和 Memcache 代理服务器，主要用于管理 Redis 和 Memcached 集群，减少与Cache 服务器直接连接的数量。Twemproxy作为代理，可接受来自多个程序的访问，按照路由规则，转发给后台的各个Redis服务器，再原路返回。该方案很好的解决了单个Redis实例承载能力的问题。

40.写代码实现redis事务操作。

Redis会将一个事务中的所有命令序列化，然后按顺序执行

multi   //开启一个事务
set age 10 //暂存指令队列
set age 20
exec    //开始执行（提交事务）
或
discard //清空指令队列（事务回滚）

41.redis中的watch的命令的作用？

Redis Watch 命令用于监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。当某个事务需要按条件执行时，就要使用这个命令将给定的键设置为受监控的

42.基于redis如何实现商城商品数量计数器？

指定键的值做加加操作，返回加后的结果。

参考链接：https://www.cnblogs.com/JockChou/p/4647973.html

43.简述redis分布式锁和redlock的实现机制。

在不同进程需要互斥地访问共享资源时，分布式锁是一种非常有用的技术手段。
一个Client想要获得一个锁需要以下几个操作：

得到本地时间Client使用相同的key和随机数,按照顺序在每个Master实例中尝试获得锁。在获得锁的过程中，为每一个锁操作设置一个快速失败时间(如果想要获得一个10秒的锁， 那么每一个锁操作的失败时间设为5-50ms)。
这样可以避免客户端与一个已经故障的Master通信占用太长时间，通过快速失败的方式尽快的与集群中的其他节点完成锁操作。

客户端计算出与master获得锁操作过程中消耗的时间，当且仅当Client获得锁消耗的时间小于锁的存活时间，并且在一半以上的master节点中获得锁。才认为client成功的获得了锁。

如果已经获得了锁，Client执行任务的时间窗口是锁的存活时间减去获得锁消耗的时间。
如果Client获得锁的数量不足一半以上，或获得锁的时间超时，那么认为获得锁失败。客户端需要尝试在所有的master节点中释放锁， 即使在第二步中没有成功获得该Master节点中的锁，仍要进行释放操作。

44.什么是一致性哈希？Python中是否有相应模块？

对节点和数据，都做一次哈希运算，然后比较节点和数据的哈希值，数据取和节点最相近的节点做为存放节点。这样就保证当节点增加或者减少的时候，影响的数据最少。
hash_ring 是python中做一致性哈希的模块

45.如何高效的找到redis中所有以oldboy开头的key？

key oldboy*