科技资讯_数据资讯

Mysql索引原理浅析

「深度学习福利」大神带你进阶工程师,立即查看>>>
一、mysql体系结构
二、mysql索引
1、定义
索引是为了加速对表中的数据行的检索而创造的一种分散存储的数据结构
2、索引的实现
mysql的索引是由存储引擎来实现,不同的存储引擎实现方式不同。
3、存放位置
一般是存放在磁盘中
4、作用减少扫描的数据行可以把随机IO变成顺序IO 可以帮助我们在分组、排序等操作时,避免使用临时表
5、索引结构
我们都知道mysql的索引使用B树来实现的,那么为什么会考虑B树,不考虑其他数据结构呢？
5.1 首先我们来看普通的二叉树。
普通的二叉树不是绝对平衡的,会有一个问题,如下图：
它有可能会形成一个链表,这样就失去了二叉树的优势,需要遍历查找,性能查。
5.2 那么如果我们选择平衡二叉树呢？如下图：

平衡二叉树没有普通二叉树可能会形成链表的问题,但是它还有其他的问题。
a、它太深了这里的太深是指树的高度,大家不要想歪了～如果在数据量很大的情况下,这棵树的高度很可能成千上万,因此它的IO次数也会很频繁,会严重影响性能
b、它太小了太小指的是每一个磁盘块（节点）保存的数据量太小了没有利用好操作磁盘IO的数据交换特性（4K）没有利用好磁盘IO的预读能力（空间局部性原理）
这里解释下为什么说没有利用好。
1、操作系统磁盘IO的数据交换一次默认是4KB大小,但是我们的节点里面存储的数据远远小于4KB,即我们进行了一次IO但是没有完全利用这次IO的数据交换大小,造成浪费。
2、操作系统磁盘IO具备预读能力,是什么意思呢？比如我们要读取一张20KB大小的jpg图片,我们第一次读了4KB的头内容,操作系统会认为我们可能需要接下来的16KB的剩余内容,所以会一次性把剩余的内容都传输给我们。
5.3 那么如果我们选择B-Trees即多路平衡查找树呢？如下图：
这里我选择的是一个3路的平衡查找树。（即一个节点最多可以有3-1=2个元素）
可以看出同样的高度,它比平衡二叉树存储的数据多得多,减少了IO次数,同时每次IO获取的数据也更多,提升了IO效率。
5.4 最后来看下B+Trees即加强版多路平衡查找树。如下图：

它有以下几个特点：采用闭合区间非叶子节点不保存数据,只保存关键字和子节点的引用关键字对应的数据保存在叶子节点中叶子节点是顺序排列的,并且相邻的节点具有顺序引用的关系
5.5 那么我们为什么要采用B+Trees呢？拥有多路的优势扫表能力强磁盘IO能力强排序能力强查询能力更稳定
这里我解释下为什么说B+Trees的查询能力更稳定：
B-Trees可能扫秒到第一层就返回,也可能扫秒到最后一层才返回。可能很快也可能很慢。
B+Trees每次都要扫面到最后一层,因此速度更加稳定。
6、B树在存储引擎中的实现方式
6.1、Myisam
非聚簇索引,数据和索引分别存储。索引文件xx.MYI 数据文件xx.MYD 叶子节点保存的是引用地址而非数据
6.2、InnoDB
聚簇索引,数据和索引保存在一起文件xx.ibd 在叶子节点保存对应的所有数据以主键索引来组织数据,没有主键的话,会帮我们隐式创建主键索引辅助索引不存地址,存主键,这样便于维护
7、列的离散性列的离散性在索引中是一种很重要的指标。列的离散性 x = count(distinct col) : count(col) 比例越大,离散性越高,选择性就越好下面我们看个例子来理解：
name的列的离散性 x1 = 5 : 5 = 1 sex的列的离散性 x2 = 2 : 5 = 0.4 x1>x2,所以sex的列的离散性低,可选择性差。可选择性差是什么意思呢？比如有如上100W的数据,现在我们要查找sex=男的,那么在索引中我们可选择的范围太大了,因为只有男或者女,查询效率就很低在mysql查询优化器中,如果列的离散性低的话,可能就不走索引,直接全表扫描
8、联合索引
8.1 建立联合索引的原则：经常用的列优先离散性高的列优先宽度小的列优先
8.2 适用性：如果不是最左匹配,则无法使用联合索引 where id = ? and age > ? 第二列是范围判断的,走联合索引 where id > ? and age = ? 第一列是范围判断的,不走联合索引
9、覆盖索引定义：如果查询的列可以通过索引节点的关键字直接返回,则称之为覆盖索引 ex: index_name
覆盖：select name from user where name= ?
非覆盖：select * from user where name= ? 覆盖索引可以减少数据库IO操作,不用再走到B树的叶子节点获取数据,而是在子节点就可以获取关键字进行返回。
10、建立索引的原则索引不易建多：维护B+Trees成本高,插入、更新、删除等操作要做很多逻辑判断索引列的长度不易过长：可以有效减少索引的磁盘占用提高查询效率

数据库

2019-05-05 16:20:00

宜信-运维-数据库|SQL优化：一篇文章说清楚Oracle Hint的正确使用姿势

「深度学习福利」大神带你进阶工程师,立即查看>>>
一、提示（Hint）概述
1、为什么引入Hint?
Hint是Oracle数据库中很有特色的一个功能,是很多DBA优化中经常采用的一个手段。那为什么Oracle会考虑引入优化器呢？基于代价的优化器是很聪明的,在绝大多数情况下它会选择正确的优化器,减轻DBA的负担。
但有时它也聪明反被聪明误,选择了很差的执行计划,使某个语句的执行变得奇慢无比。此时就需要DBA进行人为的干预,告诉优化器使用指定的存取路径或连接类型生成执行计划,从而使语句高效地运行。Hint就是Oracle提供的一种机制,用来告诉优化器按照告诉它的方式生成执行计划。
2、不要过分依赖Hint
当遇到SQL执行计划不好的情况,应优先考虑统计信息等问题,而不是直接加Hint了事。如果统计信息无误,应该考虑物理结构是否合理,即没有合适的索引。只有在最后仍然不能SQL按优化的执行计划执行时,才考虑Hint。
毕竟使用Hint,需要应用系统修改代码,Hint只能解决一条SQL的问题,并且由于数据分布的变化或其他原因(如索引更名)等,会导致SQL再次出现性能问题。
3、Hint的弊端 Hint是比较"暴力"的一种解决方式,不是很优雅。需要开发人员手工修改代码。 Hint不会去适应新的变化。比如数据结构、数据规模发生了重大变化,但使用Hint的语句是感知变化并产生更优的执行计划。 Hint随着数据库版本的变化,可能会有一些差异、甚至废弃的情况。此时,语句本身是无感知的,必须人工测试并修正。
4、Hint与注释关系
提示是Oracle为了不破坏和其他数据库引擎之间对SQL语句的兼容性而提供的一种扩展功能。Oracle决定把提示作为一种特殊的注释来添加。它的特殊性表现在提示必须紧跟着DELETE、INSERT、UPDATE或MERGE关键字。
换句话说,提示不能像普通注释那样在SQL语句中随处添加。且在注释分隔符之后的第一个字符必须是加号。在后面的用法部分,会详细说明。
5、Hint功能
Hint提供的功能非常丰富,可以很灵活地调整语句的执行过程。通过Hint,我们可以调整：优化器类型优化器优化目标数据读取方式(访问路径) 查询转换类型表间关联的顺序表间关联的类型并行特性其他特性
二、Hint用法
1、语法
1）关键字说明 DELETE、INSERT、SELECT和UPDATE是标识一个语句块开始的关键字,包含提示的注释只能出现在这些关键字的后面,否则提示无效。 "+"号表示该注释是一个提示,该加号必须立即跟在"/*"的后面,中间不能有空格。 hint是下面介绍的具体提示之一,如果包含多个提示,则每个提示之间需要用一个或多个空格隔开。 text是其它说明hint的注释性文本
2）提示中的错误
提示中的语法错误不会报错,如果解析器不能解析它,就会把它看做一个普通注释处理。这也是容易造成困惑的一点,使用的Hint到底是否起效？可以采用一些手段,检查提示的有效性。需要注意的是,那些语法正确但引用对象错误的提示是不会被报告的。 explain plan + dbms_xplan
使用dbms_xplan输出中的note选项。 10132事件
在10g中,这个事件产生的输出文档的末尾有一部分内容专门讲提示。通过它可以检查两个方面:一是每个用到的提示都会被列出来。如果漏掉了哪个,就说明这个提示没有被识别；二是检查是否有一些信息指明了出现提示错误(如果出错,err值将大于0)。
3）提示中的对象
SELECT /*+ INDEX(table_name index_name) */ ... table_name是必须要写的,且如果在查询中使用了表的别名,在hint也要用表的别名来代替表名。 index_name可以不必写,Oracle会根据统计值选一个索引。如果索引名或表名写错了,那这个hint就会被忽略。
如果指定对象是视图,需要按此方法指定。/*+hint view.table ...*/,其中table是view中的表。
一个很常见的错误时,在使用提示的时候最易犯的错误是与表的别名有关。正确的规则是,当在提示中使用表时,只要表有别名就应该使用别名而不是表名。
2、提示的作用域查询块
初始化参数提示对整个SQL语句起作用,其他的提示仅仅对查询块起作用。仅仅对单个查询块起作用的提示,必须在它控制的查询块内指定。
例外 - 全局提示
可以使用点号引用包含在其他查询块(假设这些块已命名)中的对象。全局提示的语法可以支持两层以上的引用,对象间必须用点号分隔。
命名查询块
既然where子句中的子查询是没有命名的,它们的对象就不能被全局提示引用。为了解决这个问题,10g中使用了另一种方法来解决-命名查询块。查询优化器可以给每个查询生成一个查询块名,而且还可以使用提示qb_name手工为每个查询块命名。大多数提示都可以通过参数来指定在那个查询块中有效。
*在提示中通过@来引用一个查询块。
3、提示数据字典
Oracle在11g的版本中提供了一个数据字典—V$SQL_HINT。通过这个数据字典可以看到提示的出现版本、概要数据版本、SQL特性以及相反提示等。
INVERSE
这个hint相反操作的hint。 VERSION
代表着这个hint正式公布引入的版本。
三、Hint分类
1、和优化器相关的
当对优化器为某个语句所制定的基本执行计划不满意时,最好的办法就是通过提示来转换优化器的模式,并观察其转换后的结果,看是否已经达到期望程度。如果只通过转换优化器的模式就可以获得非常好的执行计划,则就没有必要额外使用更为复杂的提示了。 OPT_PARAM
这个提示的作用就是使我们在某条语句中指定某个系统参数值。 ALL_ROWS
为实现查询语句整体最优化而引导优化器制定最少成本的执行计划。这个提示会使优化器选择一条可最快检索所有查询行的路径,而代价就是在检索一行数据时,速度很慢。 FIRST_ROWS
为获得最佳响应时间而引导优化器制定最少成本的执行计划。这个提示会使优化器选择可最快检索出查询的第一行(或指定行)数据的路径,而代价就是检索很多行时速度就会很慢。利用FIRST_ROWS来优化的行数,默认值为1,这个值介于10到1000之间,这个使用FIRST_ROWS(n)的新方法是完全基于代价的方法。它对n很敏感,如果n值很小,CBO就会生成包含嵌套循环以及索引查找的计划；如果n很大,CBO会生成由哈希连接和全表扫描组成的计划(类似ALL_ROWS)。 CHOOSE
依据SQL中所使用到的表的统计信息存在与否,来决定使用RBO还是CBO。在CHOOSE模式下,如果能够参考表的统计信息,则将按照ALL_ROWS方式执行。除非在查询中的所有表都没有经过分析,否则choose提示会对整个查询使用基于代价的优化。如果在多表连接中有一个表经过分析过,那么就会对整个查询进行基于代价的优化。 RULE
使用基于规则的优化器来实现最优化执行,即引导优化器根据优先顺序规则来决定查询条件中所使用到的索引或运算符的执行顺序来制定执行计划。这个提示强制oracle优先使用预定义的一组规则,而不是对数据进行统计；同时该提示还会使这个语句避免使用其他提示,除了DRIVING_SITE和ORDERED(不管是否进行基于规则的优化,这两个提示都可使用)。
2、和访问路径相关的 FULL
告诉优化器通过全表扫描方式访问数据。这个提示只对所指定的表进行全表扫描,而不是查询中的所有表。FULL提示可以改善性能。这主要是因为它改变了查询中的驱动表,而不是因为全表扫描。在使用其他某些提示时,也必须使用FULL提示。只有访问整个表时,才可利用CACHE提示将表进行缓存。并行组中的某些提示也必须使用全表扫描。 CLUSTER
引导优化器通过扫描聚簇索引来从索引表中读取数据。 HASH
引导优化器按照哈希扫描的方式从表中读取数据。 INDEX
告诉优化器对指定表通过索引的方式访问数据。当访问数据会导致结果集不完整时,优化器将忽略这个Hint。 NO_INDEX
告诉优化器对指定表不允许使用索引。这个提示会禁止优化器使用指定索引。可以在删除不必要的索引之前在许多查询中禁止索引。如果使用了NO_INDEX,但是没有指定任何索引,则会执行全表扫描。如果对某个索引同时使用了NO_INDEX和会之产生冲突的提示(如INDEX),这时两个提示都会被忽略掉。 INDEX_ASC
利用索引从表中读取数据时,引导优化器对提示中所指定索引的索引列值按照升序使用范围扫描。 INDEX_COMBINE
告诉优化器强制选择位图索引。这个提示会使优化器合并表上的多个位图索引,而不是选择其中最好的索引(这是INDEX提示的用途)。还可以使用index_combine指定单个索引(对于指定位图索引,该提示优先于INDEX提示)。对于B树索引,可以使用AND_EQUAL提示而不是这个提示。 INDEX_JOIN
索引关联,当谓词中引用的列上都有索引的时候,可以通过索引关联的方式来访问数据。这个提示可以将同一个表的各个不同索引进行合并,这样就只需要访问这些索引就可以了,节省了回表查询的时间。但只能在基于代价的优化器中使用该提示。这个提示不仅允许只访问表上的索引,这样可以扫描更少的代码块,并且它比使用索引并通过rowid扫描整个表快5倍。 INDEX_DESC
利用索引从表中读取数据时,引导优化器对提示中所指定索引的索引列值按照降序使用范围扫描。 INDEX_FFS
告诉优化器以INDEX FFS(index fast full scan)的方式访问数据。INDEX_FFS提示会执行一次索引的快速全局扫描。这个提示只访问索引,而不是对应的表。只有查询需要检索的信息都在索引上时,才使用这个提示。特别在表有很多列时,使用该提示可以极大地改善性能。 INDEX_SS
强制使用index skip scan的方式访问索引。当在一个联合索引中,某些谓词条件并不在联合索引的第一列时(或者谓词并不在联合索引的第一列时),可以通过index skip scan来访问索引获得数据。当联合索引第一列的唯一值很少时,使用这种方式比全表扫描的方式效率要高。
3、和查询转换相关的 USE_CONCAT
将含有多个OR或者IN运算符所连接起来的查询语句分解为多个单一查询语句,并为每个单一查询语句选择最优化查询路径,然后再将这些最优化查询路径结合在一起,以实现整体查询语句的最优化目的。只有在驱动查询条件中包含OR的时候,才可以使用该提示。 NO_EXPAND
引导优化器不要为使用OR运算符号(或IN运算符)的条件制定相互结合的执行计划。正好和USE_CONCAT相反。 REWRITE
当表连接的对象是数据量比较大的表或者需要获得使用统计函数处理过的结果时,为了提高执行速度可预先创建物化视图。当用户要求查询某个查询语句时,优化器会在从表中和从物化视图中读取数据的两种方法中选择一个更有效的方法来读取数据。该执行方法称之为查询重写。使用REWRITE提示引导优化器按照该方式执行。 MERGE
为了能以最优方式从视图或者嵌套视图中读取数据,通过变换查询语句来直接读取视图使用的基表数据,该过程被称之为视图合并。不同的情况其具体使用类型也有所不同。该提示主要在视图未发生合并时被使用。尤其是对比较复杂的视图或者嵌套视图(比如使用了GROUP BY或DISTINC的视图)使用该提示,有时会取得非常好的效果。 UNNEST
提示优化器将子查询转换为连接的方式。也就是引导优化器合并子查询和主查询并且将其向连接类型转换。 NO_UNNEST
引导优化器让子查询能够独立地执行完毕之后再跟外围的查询做FILTER。 PUSH_PRED
使用该提示可以将视图或嵌套视图以外的查询条件推入到视图之内。 NO_PUSH_PRED
使用该提示确保视图或嵌套视图以外的查询条件不被推入到视图内部。 PUSH_SUBQ
使用该提示引导优化器为不能合并的子查询制定执行计划。不能合并的子查询被优先执行之后,该子查询的执行结果将扮演缩减主查询数据查询范围的提供者角色。通常在无法执行子查询合并的情况下,子查询扮演的都是检验者角色,所以子查询一般被放在最后执行。在无法被合并的子查询拥有较少的结果行,或者该子查询可以缩减主查询查询范围的情况下,可以使用该提示引导优化器最大程度地将该子查询放在前面执行,以提高执行速度。但如果子查询执行的是远程表或者排序合并连接的一部分连接结果,则该提示将不起任何作用。 NO_PUSH_SUBQ
使用该提示将引导优化器将不能实现合并的子查询放在最后执行。在子查询无法缩减主查询的查询范围,或者执行子查询开销较大的情况下,将这样的子查询放在最后执行可以在某种程度上提高整体的执行效率。也就是说,尽可能地使用其他查询条件最大程度地缩减查询范围之后,再执行子查询。
4、和表连接顺序相关的
这些提示可以调整表连接的顺序。调整表连接的顺序并不是只能使用这些提示,在嵌套循环连接方式中也可以让提示来引导优化器使用由驱动查询条件所创建的索引。然而,该方法只有在使用的索引和表连接顺序同时被调整的情况下才比较有效。一般而言,这些提示主要在执行多表连接和表之间的连接顺序比较混乱的情况下才使用,也在排序合并连接或哈希连接方式下,为引导优化器优先执行数据量比较少得表时使用。 LEADING
在一个多表关联的查询中,这个Hint指定由哪个表作为驱动表,即告诉优化器首先要访问那个表上的数据。引导优化器使用LEADING指定的表作为表连接顺序中的第一个表。该提示既与FROM中所描述的表的顺序无关,也与作为调整表连接顺序的ORDERED提示不同,并且在使用该提示时并不需要调整FROM中所描述的表的顺序。当该提示与ORDERED提示同时使用时,该提示被忽略。
这个提示类似ORDERED提示,它允许指定驱动查询的表,然后由优化器来判断下一个要访问的表。如果使用这个提示指定多张表,那么就可以忽略这个提示。 ORDERED
引导优化器按照FROM中所描述的表的顺序执行连接。如果和LEADING提示被一起使用,则LEADING提示将被忽略。由于ORDERED只能调整表连接的顺序并不能改变表连接的方式,所以为了改变表的连接方式,经常将USE_NL、USE_MERGE提示与ORDERED提示放在一起使用。
5、和表连接操作相关的 USE_NL
使用该提示引导优化器按照嵌套循环连接方式执行表连接。它只是指出表连接的方式,对于表连接顺序不会有任何影响。 USE_MERGE
引导优化器按照排序合并连接方式执行连接。在有必要的情况下,推荐将该提示与ORDERED提示一起使用。提示通常用于获得查询的最佳吞吐量。假设将两个表连接在一起,从每个表返回的行集将被排序,然后再被合并(也就是合并排序),从而组成最终的结果集。由于每个行先被排序之后才进行合并,所以在给定查询中检索所有行时,速度将会最快。如果需要以最快速度返回第一行,就应该使用USE_NL提示。 USE_HASH
该提示引导优化器按照哈希连接方式执行连接。在执行哈希连接时,如果由于某一边的表比较小,从而可以在内存中实现哈希连接,那么就能够获得非常好的执行速度。由于在大部分情况下优化器会通过对统计信息的分析来决定Build Input和Prove Input,所以建议不要使用ORDERED提示随意改变表的连接顺序。但是当优化器没能做出正确判断时,或者像从嵌套视图中所获得的结果集合那样不具备统计信息时,可以使用该提示。
6、和并行相关的 PARALLEL
指定SQL执行的并行度,这个值将会覆盖表自身设定的并行度。如果这个值为default,CBO使用系统参数。从表中读取大量数据和执行DML操作时使用该提示来指定SQL的并行操作。
一般情况下需要在该提示中指定将要使用的并行线程个数。如果在该提示中没有指定并行度的个数,则优化器将使用PARALLEL_THREADS_PER_CPU参数所指定的值进行自动计算。如果在定义表时指定了PARALLEL,那么在能够使用并行操作的情况下,即使没有使用该提示,优化器也会按照指定的并行级别选择并行操作。
但是如果想在DELETE、INSERT、UPDATE、MERGE等DML操作中使用并行操作,则必须要在会话中设置ALTER SESSION ENABLE PARALLEL DML。在某个会话中所设置的并行级别也可以被引用在内部的GROUP BY或者排序操作中。在并行操作中如果出现了某个限制要素,则该提示将被忽略。 NOPARALLEL/NO_PARALLEL
在SQL语句禁止使用并行。在有些版本中用NO_PARALLEL提示来代替NOPARALLEL提示。 PQ_DISTRIBUTE
为了提高并行连接的执行速度,使用该提示来定义使用何种方法在主从进程之间(例如生产者进程和消费者进程)分配各连接表的数据行。 PARALLEL_INDEX
为了按照并行操作的方式对分区索引进行索引范围扫描而使用该提示,并且可以指定进程的个数。
7、其他相关的 APPEND
让数据库以直接加载的方式(direct load)将数据加载入库。这个提示不会检查当前是否有插入所需要的块空间,相反它会直接将数据添加到新块中。这样会浪费空间,但可以提高插入的性能。需要注意的是,数据将被存储在HWM之上的位置。 APPEND_VALUES
在11.2中,Oracle新增了APPEND_VALUES提示,使得INSERT INTO VALUES语句也可以使用直接路径插入。 CACHE
在全表扫描之后,数据块将留在LRU列表的最活跃端。如果设置表的CACHE属性,它的作用和HINT一样。这个提示会将全表扫描全部缓存到内存中。如果表很大,会占用大量内存。因此适用于用户经常访问的较小的表。 NOCACHE
引导优化器将通过全表扫描方式获取的数据块缓存在LRU列表的最后位置,这样可以让数据库实例缓存中的这些数据块被优先清除。这是优化器在Buffer Cache中管理数据块的默认方法(仅针对全表扫描)。 QB_NAME
使用该提示为查询语句块命名,在其他查询语句块可以直接使用该查询语句块的名称。 DRIVING_SITE
这个提示在分布式数据库操作中有用。指定表是处理连接所在的位置。可以限制通过网络处理的信息量。此外,还可以建立远程表的本地视图来限制从远程站点检索的行。本地视图应该有where子句,从而视图可以在将行发送回本地数据库之前限制从远程数据库返回的行。 DYNAMIC_SAMPLING
提示SQL执行时动态采样的级别。这个级别为0~10,它将覆盖系统默认的动态采样级别。等级越高,所获得统计信息的准确率越高。该提示的功能就是为了确保将动态采样原理应用在单个SQL中。 AND_EQUAL
这个提示会使优化器合并表上的多个索引,而不是选择其中最好的索引(这是INDEX提示的用途)。这个提示与前面的INDEX_JOIN提示有区别,以此指定的合并索引随后需访问表,而INDEX_JOIN提示则只需访问索引。如果发现需经常用到这个提示,可能需要删除这些单个索引而改用一个组合索引。需要查询条件里面包括所有索引列,然后取得每个索引中得到的rowid列表。然后对这些对象做merge join,过滤出相同的rowid后再去表中获取数据或者直接从索引中获得数据。在10g中,and_equal已经废弃了,只能通过hint才能生效。 CARDINALITY
向优化器提供对某个查询语句的整体或部分的预测基数值,并通过参考该基数值来为查询语句制定执行计划。如果在该提示中没有指定表的名称,则该基数值将被视为从该查询语句所获得的最终结果行数。
四、Hint使用示例
下面通过一个例子说明一下提示的使用及在什么情况下提示会被忽略。
1、构建表
2、使用INDEX提示
*在某些情况下,如果CBO认为Hint会导致错误结果,那么Hint则会忽略。该例子中因为ID字段可能为空,而索引是保存空值的,因此count(*)使用索引将导致错误的结果,故而使用了全表扫描,忽略了Hint。
3、使用INDEX提示（非空字段）
*ID字段不可为空,因此COUNT可用索引扫描的方式处理,Hint生效了。
作者：韩锋
来源：宜信技术学院（ http://college.creditease.cn/）

数据库

2019-05-05 14:34:00

Oracle相关

「深度学习福利」大神带你进阶工程师,立即查看>>>
oracle system登录密码错误,修改system密码：
cmd >> sqlplus / as sysdba
sql >> alter user system account unlock;
sql >> alter user system identified by 123456;
ORA-01031:insufficient privileges报错
使用本机用户免登录修改密码时,碰到上述错误原因是没有把计算机用户添加进来,解决方案：
https://jingyan.baidu.com/article/e8cdb32b21b3c437042bad7f.html
////////////////////////////////////////////////////////////////////////////////////

数据库

2019-05-05 14:15:00

Golang Failpoint 的设计与实现

「深度学习福利」大神带你进阶工程师,立即查看>>>
作者：龙恒
对于一个大型复杂的系统来说,通常包含多个模块或多个组件构成,模拟各个子系统的故障是测试中必不可少的环节,并且这些故障模拟必须做到无侵入地集成到自动化测试系统中,通过在自动化测试中自动激活这些故障点来模拟故障,并观测最终结果是否符合预期结果来判断系统的正确性和稳定性。如果在一个分布式系统中需要专门请一位同事来插拔网线来模拟网络异常,一个存储系统中需要通过破坏硬盘来模拟磁盘损坏,昂贵的测试成本会让测试成为一场灾难,并且难以模拟一些需要精细化控制的的测试。所以我们需要一些自动化的方式来进行确定性的故障测试。
Failpoint 项目就是为此而生,它是 FreeBSD failpoints 的 Golang 实现,允许在代码中注入错误或异常行为, 并由环境变量或代码动态激活来触发这些异常行为。Failpoint 能用于各种复杂系统中模拟错误处理来提高系统的容错性、正确性和稳定性,比如：微服务中某个服务出现随机延迟、某个服务不可用。存储系统磁盘 I/O 延迟增加、I/O 吞吐量过低、落盘时间长。调度系统中出现热点,某个调度指令失败。充值系统中模拟第三方重复请求充值成功回调接口。游戏开发中模拟玩家网络不稳定、掉帧、延迟过大等,以及各种异常输入（外挂请求）情况下系统是否正确工作。 ……
为什么要重复造轮子？
etcd 团队在 2016 年开发了 gofail 极大地简化了错误注入,为 Golang 生态做出了巨大贡献。我们在 2018 年已经引入了 gofail 进行错误注入测试,但是我们在使用中发现了一些功能性以及便利性的问题,所以我们决定造一个更好的「轮子」。
如何使用 gofail 使用注释在程序中注入一个 failpoint： // gofail: var FailIfImportedChunk int // if merger, ok := scp.merger.(*ChunkCheckpointMerger); ok && merger.Checksum.SumKVS() >= uint64(FailIfImportedChunk) { // rc.checkpointsWg.Done() // rc.checkpointsWg.Wait() // panic("forcing failure due to FailIfImportedChunk") // } // goto RETURN1 // gofail: RETURN1: // gofail: var FailIfStatusBecomes int // if merger, ok := scp.merger.(*StatusCheckpointMerger); ok && merger.EngineID >= 0 && int(merger.Status) == FailIfStatusBecomes { // rc.checkpointsWg.Done() // rc.checkpointsWg.Wait() // panic("forcing failure due to FailIfStatusBecomes") // } // goto RETURN2 // gofail: RETURN2: 使用 gofail enable 命令将注释转换为代码： if vFailIfImportedChunk, __fpErr := __fp_FailIfImportedChunk.Acquire(); __fpErr == nil { defer __fp_FailIfImportedChunk.Release(); FailIfImportedChunk, __fpTypeOK := vFailIfImportedChunk.(int); if !__fpTypeOK { goto __badTypeFailIfImportedChunk} if merger, ok := scp.merger.(*ChunkCheckpointMerger); ok && merger.Checksum.SumKVS() >= uint64(FailIfImportedChunk) { rc.checkpointsWg.Done() rc.checkpointsWg.Wait() panic("forcing failure due to FailIfImportedChunk") } goto RETURN1; __badTypeFailIfImportedChunk: __fp_FailIfImportedChunk.BadType(vFailIfImportedChunk, "int"); }; /* gofail-label */ RETURN1: if vFailIfStatusBecomes, __fpErr := __fp_FailIfStatusBecomes.Acquire(); __fpErr == nil { defer __fp_FailIfStatusBecomes.Release(); FailIfStatusBecomes, __fpTypeOK := vFailIfStatusBecomes.(int); if !__fpTypeOK { goto __badTypeFailIfStatusBecomes} if merger, ok := scp.merger.(*StatusCheckpointMerger); ok && merger.EngineID >= 0 && int(merger.Status) == FailIfStatusBecomes { rc.checkpointsWg.Done() rc.checkpointsWg.Wait() panic("forcing failure due to FailIfStatusBecomes") } goto RETURN2; __badTypeFailIfStatusBecomes: __fp_FailIfStatusBecomes.BadType(vFailIfStatusBecomes, "int"); }; /* gofail-label */ RETURN2:
gofail 使用中遇到的问题使用注释的方式在代码中注入 failpoint,代码容易出错,并且没有编译器检测。只能全局生效,大型项目为了缩短自动化测试的时间会引入并行测试,不同并行任务之间会存在干扰。需要写一些 hack 代码来避免一些不必要的错误日志,比如如上代码,必须要写 // goto RETURN2 和 // gofail: RETURN2: ,并且中间必须添加一个空行,至于原因可以看 generated code 逻辑。
我们要设计一个什么样子的 failpoint？
理想的 failpoint 实现应该是什么样子？
理想中的 failpoint 应该是使用代码定义并且对业务逻辑无侵入,如果在一个支持宏的语言中 (比如 Rust),我们可以定义一个 fail_point 宏来定义 failpoint： fail_point!("transport_on_send_store", |sid| if let Some(sid) = sid { let sid: u64 = sid.parse().unwrap(); if sid == store_id { self.raft_client.wl().addrs.remove(&store_id); } })
但是我们遇到了一些问题： Golang 并不支持 macro 语言特性。 Golang 不支持编译器插件。 Golang tags 也不能提供一个比较优雅的实现 ( go build --tag="enable-failpoint-a" )。
Failpoint 设计准则使用 Golang 代码定义 failpoint,而不是注释或其他形式。 Failpoint 代码不应该有任何额外开销：不能影响正常功能逻辑,不能对功能代码有任何侵入。注入 failpoint 代码之后不能导致性能回退。 Failpoint 代码最终不能出现在最终发行的二进制文件中。 Failpoint 代码必须是易读、易写并且能引入编译器检测。最终生成的代码必须具有可读性。生成代码中,功能逻辑代码的行号不能发生变化（便于调试）。支持并行测试,可以通过 context.Context 控制一个某个具体的 failpoint 是否激活。
Golang 如何实现一个类似 failpoint 宏？
宏的本质是什么？如果追本溯源,发现其实可以通过 AST 重写在 Golang 中实现满足以上条件的 failpoint,原理如下图所示：
[图片上传失败...(image-6d3dee-1557978922311)]
对于任何一个 Golang 代码的源文件,可以通过解析出这个文件的语法树,遍历整个语法树,找出所有 failpoint 注入点,然后对语法树重写,转换成想要的逻辑。
相关概念
Failpoint
Failpoint 是一个代码片段,并且仅在对应的 failpoint name 激活的情况下才会执行,如果通过 failpoint.Disable("failpoint-name-for-demo") 禁用后,那么对应的的 failpoint 永远不会触发。所有 failpoint 代码片段不会编译到最终的二进制文件中,比如我们模拟文件系统权限控制： func saveTo(path string) error { failpoint.Inject("mock-permission-deny", func() error { // It's OK to access outer scope variable return fmt.Errorf("mock permission deny: %s", path) }) }
Marker 函数
AST 重写阶段标记需要被重写的部分,主要有以下功能：提示 Rewriter 重写为一个相等的 IF 语句。标记函数的参数是重写过程中需要用到的参数。标记函数是一个空函数,编译过程会被 inline,进一步被消除。标记函数中注入的 failpoint 是一个闭包,如果闭包访问外部作用域变量,闭包语法允许捕获外部作用域变量,则不会出现编译错误,同时转换后的的代码是一个 IF 语句,IF 语句访问外部作用域变量不会产生任何问题,所以闭包捕获只是为了语法合法,最终不会有任何额外开销。简单、易读、易写。引入编译器检测,如果 Marker 函数的参数不正确,程序不能通过编译的,进而保证转换后的代码正确性。
目前支持的 Marker 函数列表： func Inject(fpname string , fpblock func(val Value)) {} func InjectContext(fpname string , ctx context.Context , fpblock func(val Value)) {} func Break(label ...string) {} func Goto(label string) {} func Continue(label ...string) {} func Return(results ...interface{}) {} func Fallthrough() {} func Return(results ...interface{}) {} func Label(label string) {}
如何在你的程序中使用 failpoint 进行注入？
最简单的方式是使用 failpoint.Inject 在调用的地方注入一个 failpoint,最终 failpoint.Inject 调用会重写为一个 IF 语句,其中 mock-io-error 用来判断是否触发, failpoint-closure 中的逻辑会在触发后执行。比如我们在一个读取文件的函数中注入一个 I/O 错误： failpoint.Inject("mock-io-error", func(val failpoint.Value) error { return fmt.Errorf("mock error: %v", val.(string)) })
最终转换后的代码如下： if ok, val := failpoint.Eval(_curpkg_("mock-io-error")); ok { return fmt.Errorf("mock error: %v", val.(string)) }
通过 failpoint.Enable("mock-io-error", "return("disk error")") 激活程序中的 failpoint,如果需要给 failpoint.Value 赋一个自定义的值,则需要传入一个 failpoint expression,比如这里 return("disk error") ,更多语法可以参考 failpoint 语法。
闭包可以为 nil ,比如 failpoint.Enable("mock-delay", "sleep(1000)") ,目的是在注入点休眠一秒,不需要执行额外的逻辑。 failpoint.Inject("mock-delay", nil) failpoint.Inject("mock-delay", func(){})
最终会产生以下代码： failpoint.Eval(_curpkg_("mock-delay")) failpoint.Eval(_curpkg_("mock-delay"))
**如果我们只想在 failpoint 中执行一个 panic,不需要接收 failpoint.Value ,则我们可以在闭包的参数中忽略这个值。**例如： failpoint.Inject("mock-panic", func(_ failpoint.Value) error { panic("mock panic") }) // OR failpoint.Inject("mock-panic", func() error { panic("mock panic") })
最佳实践是以下这样： failpoint.Enable("mock-panic", "panic") failpoint.Inject("mock-panic", nil) // GENERATED CODE failpoint.Eval(_curpkg_("mock-panic"))
为了可以在并行测试中防止不同的测试任务之间的干扰,可以在 context.Context 中包含一个回调函数,用于精细化控制 failpoint 的激活与关闭： failpoint.InjectContext(ctx, "failpoint-name", func(val failpoint.Value) { fmt.Println("unit-test", val) })
转换后的代码： if ok, val := failpoint.EvalContext(ctx, _curpkg_("failpoint-name")); ok { fmt.Println("unit-test", val) }
使用 failpoint.WithHook 的示例： func (s *dmlSuite) TestCRUDParallel() { sctx := failpoint.WithHook(context.Backgroud(), func(ctx context.Context, fpname string) bool { return ctx.Value(fpname) != nil // Determine by ctx key }) insertFailpoints = map[string]struct{} { "insert-record-fp": {}, "insert-index-fp": {}, "on-duplicate-fp": {}, } ictx := failpoint.WithHook(context.Backgroud(), func(ctx context.Context, fpname string) bool { _, found := insertFailpoints[fpname] // Only enables some failpoints. return found }) deleteFailpoints = map[string]struct{} { "tikv-is-busy-fp": {}, "fetch-tso-timeout": {}, } dctx := failpoint.WithHook(context.Backgroud(), func(ctx context.Context, fpname string) bool { _, found := deleteFailpoints[fpname] // Only disables failpoints. return !found }) // other DML parallel test cases. s.RunParallel(buildSelectTests(sctx)) s.RunParallel(buildInsertTests(ictx)) s.RunParallel(buildDeleteTests(dctx)) }
如果我们在循环中使用 failpoint,可能我们会使用到其他的 Marker 函数： failpoint.Label("outer") for i := 0; i < 100; i++ { inner: for j := 0; j < 1000; j++ { switch rand.Intn(j) + i { case j / 5: failpoint.Break() case j / 7: failpoint.Continue("outer") case j / 9: failpoint.Fallthrough() case j / 10: failpoint.Goto("outer") default: failpoint.Inject("failpoint-name", func(val failpoint.Value) { fmt.Println("unit-test", val.(int)) if val == j/11 { failpoint.Break("inner") } else { failpoint.Goto("outer") } }) } } }
以上代码最终会重写为如下代码： outer: for i := 0; i < 100; i++ { inner: for j := 0; j < 1000; j++ { switch rand.Intn(j) + i { case j / 5: break case j / 7: continue outer case j / 9: fallthrough case j / 10: goto outer default: if ok, val := failpoint.Eval(_curpkg_("failpoint-name")); ok { fmt.Println("unit-test", val.(int)) if val == j/11 { break inner } else { goto outer } } } } }
为什么会有 label 、 break 、 continue 和 fallthrough 相关 Marker 函数? 为什么不直接使用关键字？ Golang 中如果某个变量或则标签未使用,是不能通过编译的。 label1: // compiler error: unused label1 failpoint.Inject("failpoint-name", func(val failpoint.Value) { if val.(int) == 1000 { goto label1 // illegal to use goto here } fmt.Println("unit-test", val) }) break 和 continue 只能在循环上下文中使用,在闭包中使用。
一些复杂的注入示例
示例一：在 IF 语句的 INITIAL 和 CONDITIONAL 中注入 failpoint if a, b := func() { failpoint.Inject("failpoint-name", func(val failpoint.Value) { fmt.Println("unit-test", val) }) }, func() int { return rand.Intn(200) }(); b > func() int { failpoint.Inject("failpoint-name", func(val failpoint.Value) int { return val.(int) }) return rand.Intn(3000) }() && b < func() int { failpoint.Inject("failpoint-name-2", func(val failpoint.Value) { return rand.Intn(val.(int)) }) return rand.Intn(6000) }() { a() failpoint.Inject("failpoint-name-3", func(val failpoint.Value) { fmt.Println("unit-test", val) }) }
上面的代码最终会被重写为： if a, b := func() { if ok, val := failpoint.Eval(_curpkg_("failpoint-name")); ok { fmt.Println("unit-test", val) } }, func() int { return rand.Intn(200) }(); b > func() int { if ok, val := failpoint.Eval(_curpkg_("failpoint-name")); ok { return val.(int) } return rand.Intn(3000) }() && b < func() int { if ok, val := failpoint.Eval(_curpkg_("failpoint-name-2")); ok { return rand.Intn(val.(int)) } return rand.Intn(6000) }() { a() if ok, val := failpoint.Eval(_curpkg_("failpoint-name-3")); ok { fmt.Println("unit-test", val) } }
示例二：在 SELECT 语句的 CASE 中注入 failpoint 来动态控制某个 case 是否被阻塞 func (s *StoreService) ExecuteStoreTask() { select { case <-func() chan *StoreTask { failpoint.Inject("priority-fp", func(_ failpoint.Value) { return make(chan *StoreTask) }) return s.priorityHighCh }(): fmt.Println("execute high priority task") case <- s.priorityNormalCh: fmt.Println("execute normal priority task") case <- s.priorityLowCh: fmt.Println("execute normal low task") } }
上面的代码最终会被重写为： func (s *StoreService) ExecuteStoreTask() { select { case <-func() chan *StoreTask { if ok, _ := failpoint.Eval(_curpkg_("priority-fp")); ok { return make(chan *StoreTask) }) return s.priorityHighCh }(): fmt.Println("execute high priority task") case <- s.priorityNormalCh: fmt.Println("execute normal priority task") case <- s.priorityLowCh: fmt.Println("execute normal low task") } }
示例三：动态注入 SWITCH CASE switch opType := operator.Type(); { case opType == "balance-leader": fmt.Println("create balance leader steps") case opType == "balance-region": fmt.Println("create balance region steps") case opType == "scatter-region": fmt.Println("create scatter region steps") case func() bool { failpoint.Inject("dynamic-op-type", func(val failpoint.Value) bool { return strings.Contains(val.(string), opType) }) return false }(): fmt.Println("do something") default: panic("unsupported operator type") }
以上代码最终会重写为如下代码： switch opType := operator.Type(); { case opType == "balance-leader": fmt.Println("create balance leader steps") case opType == "balance-region": fmt.Println("create balance region steps") case opType == "scatter-region": fmt.Println("create scatter region steps") case func() bool { if ok, val := failpoint.Eval(_curpkg_("dynamic-op-type")); ok { return strings.Contains(val.(string), opType) } return false }(): fmt.Println("do something") default: panic("unsupported operator type") }
除了上面的例子之外,还可以写的更加复杂的情况：由 INITIAL 语句、 CONDITIONAL 表达式,以及 POST 语句组成的循环 FOR RANGE 语句 SWITCH INITIAL 语句 Slice 的构造和索引结构体动态初始化 ……
实际上,任何你可以调用函数的地方都可以注入 failpoint,所以请发挥你的想象力。
Failpoint 命名最佳实践
上面生成的代码中会自动添加一个 _curpkg_ 调用在 failpoint-name 上,是因为名字是全局的,为了避免命名冲突,所以会在最终的名字中包含包名, _curpkg_ 相当一个宏,在运行的时候自动使用包名进行展开。你并不需要在自己的应用程序中实现 _curpkg_ ,它在执行 failpoint-ctl enable 命令的时候自动生成以及自动添加,并在执行 failpoint-ctl disable 命令的时候被删除。 package ddl // ddl’s parent package is `github.com/pingcap/tidb` func demo() { // _curpkg_("the-original-failpoint-name") will be expanded as `github.com/pingcap/tidb/ddl/the-original-failpoint-name` if ok, val := failpoint.Eval(_curpkg_("the-original-failpoint-name")); ok {...} }
因为同一个包下面的所有 failpoint 都在同一个命名空间,所以需要小心命名来避免命名冲突,这里有一些推荐的规则来改善这种情况：保证名字在包内是唯一的。使用一个自解释的名字。
可以通过环境变量来激活 failpoint： GO_FAILPOINTS="github.com/pingcap/tidb/ddl/renameTableErr=return(100);github.com/pingcap/tidb/planner/core/illegalPushDown=return(true);github.com/pingcap/pd/server/schedulers/balanceLeaderFailed=return(true)"
致谢感谢 gofail 提供最初实现,给我们提供了灵感,让我们能站在巨人的肩膀上对 failpoint 进行迭代。感谢 FreeBSD 定义语法规范。
最后,欢迎大家和我们交流讨论,一起完善 Failpoint 项目。
原文链接： https://pingcap.com/blog-cn/golang-failpoint/

数据库

2019-05-05 13:50:00

MySQL EXPLAIN 执行计划详解

「深度学习福利」大神带你进阶工程师,立即查看>>>
一 .介绍　　EXPLAIN 命令用于SQL语句的查询执行计划。这条命令的输出结果能够让我们了解MySQL 优化器是如何执行SQL 语句的。这条命令并没有提供任何调整建议,但它能够提供重要的信息帮助你做出调优决策。
先解析一条sql语句,你可以看出现什么内容
?
1
EXPLAIN SELECT * FROM person,dept WHERE person.dept_id = dept.did and person.salary >20000

下面咱们详细的介绍一下查询计划的结果列: 二. id : 查询序列号
　查询序号即为sql语句执行顺序 ?
1
EXPLAIN select * from person where dept_id =( select did from dept where dname = 'python' );

从 2 个表中查询,对应输出 2 行,每行对应一个表, id 列表示执行顺序,id 越大,越先执行,id 相同时,由上至下执行。三.select_type : 查询类型
　　select_type 列提供了对表的查询类型。最常见的值包括 SIMPLE、PRIMARY、DERIVED 和UNION 。其他可能的值还有 UNION RESULT 、 SUBQUERY 等等.
　2.1 simple 简单查询 (没有union和子查询)
　　对于不包含子查询和其他复杂语法的简单查询,这是一个常见的类型。 ?
1
EXPLAIN SELECT * FROM person;

　2.2 primary 最外层查询 (在存在子查询的语句中,最外面的select查询就是primary)
　　这是为更复杂的查询而创建的首要表(也就是最外层的表)。这个类型通常可以在DERIVED 和 UNION 类型混合使用时见到。
　2.3 derived 子查询( 在FROM列表中包含的子查询 )
　　当一个表不是一个物理表时,那么这个就被叫做DERIVED ?
1
EXPLAIN SELECT * FROM ( SELECT * FROM person LIMIT 5) AS s

　2.4 subquery 映射为子查询( 在SELECT或WHERE列表中包含了子查询 )
　　这个select-type 的值是为使用子查询而定义的. ?
1
EXPLAIN SELECT person.*,( select 2 from person as p2) FROM person where dept_id = ( select did from dept where dname= 'python' );

2.5 union 联合 ?
1
EXPLAIN SELECT * FROM person union all select * from person ;

2.6 union result 使用联合的结果 ?
1
EXPLAIN SELECT * FROM person union select * from person ;

四. table 输出的行所用的表 ?
1
EXPLAIN SELECT * FROM person;

注意: table 列是EXPLAIN 命令输出结果中的一个单独行的唯一标识符。这个值可能是表名、表的别名或者一个为查询产生临时表的标识符,如派生表、子查询或集合。五. type 连接类型
　　type 列代表表示查询计划的连接类型, 有多个参数,先从最佳类型到最差类型介绍重要且困难
　　性能： null > system/const > eq_ref > ref > ref_or_null >index_merge > range > index > all
4.1 type=NULL　在优化过程中就已得到结果,不用再访问表或索引。 ?
1
EXPLAIN SELECT max (id) FROM person;

4.2 type=const/system 常量
　　在整个查询过程中这个表最多只会有一条匹配的行,比如主键 id=1 就肯定只有一行；
表最多有一个匹配行,const用于比较primary key 或者unique索引。因为只匹配一行数据,所以一定是用到primary key 或者unique 情况下才会是const,看下面这条语句 ?
1
EXPLAIN SELECT * FROM person where id =2;

所以说可以理解为const是最优化的。

4.3 type=eq_ref 使用有唯一性索引查找（主键或唯一性索引）
　对于eq_ref的解释,mysql手册是这样说的:"对于每个来自于前面的表的行组合,从该表中读取一行。这可能是最好的联接类型,除了const类型。它用在一个索引的所有部分被联接使用并且索引是UNIQUE或PRIMARY KEY"。eq_ref可以用于使用=比较带索引的列。看下面的语句　 ?
1
EXPAIN select * from person,dept where person.id = dept.did;
得到的结果是下图所示。很明显,mysql使用eq_ref联接来处理 dept 表。　　
4.4 type=ref　非唯一性索引访问
　　这是一种索引访问（有时也叫做索引查找）,它返回所有匹配某个单个值的行,然而,它可能会找到多个符合条件的行。因此,它是查找和扫描的混合体,此类索引访问只有当使用非唯一性索引或者唯一性索引的非唯一性前缀时才会发生。把它叫做ref是因为索引要跟某个参考值相比较。这个参考值或者是一个常数,或者是来自多表查询前一个表里的结果值。 ?
1
EXPLAIN select * from person where name = 'alex' ;

4.5 ref_or_null 该联接类型如同ref类似,结果包含空行.
上面这五种情况都是很理想的索引使用情况
4.6 type=range
　　索引范围扫描,常见于　<,<=,>,>=,between,in等操作符。　 ?
1
EXPLAIN select * from person where id BETWEEN 1 and 5;

4.7 type=index
　　该联接类型与ALL相同都是扫描表,但index只对索引树进行扫描,而ALL是是对数据表文件的扫描。这通常比ALL快,因为索引文件通常比数据文件小。（也就是说虽然all和Index都是读全表,但index是从索引中读取的,而all是从硬盘中读的）主要优点是避免了排序,因为索引是排好序的。
Extra列中看到“Using index”,说明mysql正在使用覆盖索引,只扫描索引的数据。　 ?
1
EXPLAIN select id, name from person;

4.8 type=ALL
　　对于每个来自于先前的表的行组合,进行完整的表扫描。如果表是第一个没标记const的表,这通常不好,并且通常在它情况下很差。通常可以增加更多的索引而不要使用ALL,使得行能基于前面的表中的常数值或列值被检索出。 ?
1
EXPLAIN select * from person;

六. possible_keys : 　　该 possible_keys列表示MySQL可以从中选择查找表中的行的索引。如果此列是NULL,则没有相关的索引。在这种情况下,您可以通过检查WHERE 子句来检查是否引用某些适合索引的列,从而提高查询的性能。如果是这样,请创建一个适当的索引并使用 EXPLAIN再次检查查询。
另外如果这个列出现大量可能被使用的索引(例如多于3 个), 那么这意味着备选索引数量太多了,同时也可能提示存在无效的索引。
七. key : 　该key 列指出mysql优化器决定选择使用哪个索引来优化对该表的访问。一般来说SQL查询中的每个表都只会使用一个索引。但是也存在索引合并的少数例外情况,如给定表上用到了两个或者更多索引。查询过程中由优化器来决定实际使用的索引。如果possible_keys索引列表中没有适合查找行的索引,那么这个key可能会命名一个不存在于该possible_keys值中的索引。简单且重要
八. key_len : 　　该key_len 列定义了mysql在索引里使用的字节数。如果mysql正在使用的只是索引里的某些列,那么就可以用这个值来算出具体是哪些列。在mysql5.5及以前的版本里,只能使用索引的最左前缀。例如,sakila.film_actor的主键是两个SMALLINT列,并且每个SMALLINT列是两个字节,那么索引中的每项是4个字节。也即说明key_len通过查找表的定义而被计算出,而不是表中的数据。
在不损失精确性的情况下,长度越短越好.
九. ref : 　　ref 列显示使用哪个列或常数与key一起从表中选择数据行。指出对 key 列所选择的索引的查找方式,常见的值有 const, func, NULL, 具体字段名。当 key 列为 NULL ,即不使用索引时。如果值是func,则使用的值是某个函数的结果
create table a11(id int primary key , age int ); insert into a11 value( 1 , 10 ),( 2 , 10 ); mysql > desc select * from a11 where age = 10 ; + -- --+-------------+-------+------+---------------+------+---------+------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | + -- --+-------------+-------+------+---------------+------+---------+------+------+-------------+ | 1 | SIMPLE | a11 | ALL | NULL | NULL | NULL | NULL | 2 | Using where | + -- --+-------------+-------+------+---------------+------+---------+------+------+-------------+ 注意:当 key 列为 NULL , ref 列也相应为 NULL 。 mysql > desc select * from a11 where id = 1 ; + -- --+-------------+-------+-------+---------------+---------+---------+-------+------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | + -- --+-------------+-------+-------+---------------+---------+---------+-------+------+-------+ | 1 | SIMPLE | a11 | const | PRIMARY | PRIMARY | 4 | const | 1 | | + -- --+-------------+-------+-------+---------------+---------+---------+-------+------+-------+ 注意:这次 key 列使用了主键索引, where id = 1 中 1 为常量, ref 列的 const 便是指这种常量。

十.row : 　　这一列是mysql评估为了找到所需的行而要读取的行数。这个数字是内嵌循环关联计划里的循环数目,也就是说它不是mysql认为它最终要从表里读取出来的行数,而是mysql为了找到符合查询的每一点上标准的那些行而必须读取的行的平均数。
rows 列提供了试图分析所有存在于累计结果集中的行数目的MySQL 优化器估计值。执行计划很容易描述这个很困难的统计量。
查询中总的读操作数量是基于合并之前行的每一行的rows 值的连续积累而得出的。这是一种嵌套行算法。
简单且重要,数值越大越不好,说明没有用好索引
十一.Extra: 　该列包含 MySQL 查询的详细信息。
　10.1 Not exists : 不存在信息
　10.2 range checked for each record :没有找到合适的索引
　10.3 Using index condition :出现这个说明mysql使用了覆盖索引,避免访问了表的数据行,效率不错！
建表及插入数据： create table a13 (id int primary key , age int ); insert into a13 value( 1 , 10 ),( 2 , 10 ); mysql > explain select id from a13; + -- --+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | Extra | + -- --+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------------+ | 1 | SIMPLE | a13 | NULL | index | NULL | PRIMARY | 4 | NULL | 2 | Using index | + -- --+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------------+ 因为 id 为主键索引,索引中直接包含了 id 的值,所以无需访问表,直接查找索引就能返回结果。 mysql > explain select age from a13; + -- --+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | Extra | + -- --+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+ | 1 | SIMPLE | a13 | NULL | ALL | NULL | NULL | NULL | NULL | 2 | NULL | + -- --+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+ age 列没有索引,因此没有 Using index ,意即需要访问表。为 age 列添加索引： create table a14 (id int primary key , age int ); insert into a14 value( 1 , 10 ),( 2 , 10 ); create index age on a14(id, age); mysql > explain select age from a14; + -- --+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | Extra | + -- --+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+ | 1 | SIMPLE | a14 | NULL | index | NULL | age | 9 | NULL | 2 | Using index | + -- --+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+ 现在索引 age 中也包含了 age 列的值,因此不用访问表便能返回结果了。
　10.4 using temporary ：mysql对查询结果进行排序的时候使用了一张临时表。
mysql > EXPLAIN SELECT p.id,d.did from person p LEFT JOIN dept d ON p.dept_id = d.did group by p.dept_id ORDER BY p.dept_id; + -- --+-------------+-------+--------+---------------+---------+---------+------------+------+---------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | + -- --+-------------+-------+--------+---------------+---------+---------+------------+------+---------------------------------+ | 1 | SIMPLE | p | ALL | NULL | NULL | NULL | NULL | 8 | Using temporary ; Using filesort | | 1 | SIMPLE | d | eq_ref | PRIMARY | PRIMARY | 4 | test.p.dept_id | 1 | Using where ; Using index | 我们发现在执行这条SQL语句时出现了 using temporary ,我们再来看看下面这条SQL语句,去掉条件中 group by 分组 mysql > EXPLAIN SELECT p.id,d.did from person p LEFT JOIN dept d ON p.dept_id = d.did ORDER BY p.dept_id; + -- --+-------------+-------+--------+---------------+---------+---------+------------+------+--------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | + -- --+-------------+-------+--------+---------------+---------+---------+------------+------+--------------------------+ | 1 | SIMPLE | p | ALL | NULL | NULL | NULL | NULL | 8 | Using filesort | | 1 | SIMPLE | d | eq_ref | PRIMARY | PRIMARY | 4 | test.p.dept_id | 1 | Using where ; Using index | + -- --+-------------+-------+--------+---------------+---------+---------+------------+------+--------------------------+ 而为什么第一个用了临时表,而第二个没有用呢？因为如果有GROUP BY子句,或者如果GROUP BY中的字段都来自其他的表而非连接顺序中的第一个表的话,就会创建一个临时表了。那么如何解决呢? 咱们为group by 字段添加一个索引 mysql > alter table person add index did_idx(dept_id); Query OK, 0 rows affected mysql > EXPLAIN SELECT p.id,d.did from person p LEFT JOIN dept d ON p.dept_id = d.did group by p.dept_id ORDER BY p.dept_id; + -- --+-------------+-------+--------+---------------+---------+---------+------------+------+--------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | + -- --+-------------+-------+--------+---------------+---------+---------+------------+------+--------------------------+ | 1 | SIMPLE | p | index | NULL | did_idx | 5 | NULL | 8 | Using index | | 1 | SIMPLE | d | eq_ref | PRIMARY | PRIMARY | 4 | test.p.dept_id | 1 | Using where ; Using index | + -- --+-------------+-------+--------+---------------+---------+---------+------------+------+--------------------------+ 为什么添加个索引就不会创建临时表了呢? 原因就在于 SQL查询时优先在索引树中执行,如果索引树满足不了当前SQL,才会进行数据表查询,那么现在加了索引, 已经可以满足查询条件了,就没有必要创建临时表了
　10.5 using filesort： mysql对数据不是按照表内的索引顺序进行读取,而是使用了其他字段重新排序.
mysql > EXPLAIN select * from person ORDER BY id; + -- --+-------------+--------+-------+---------------+---------+---------+------+------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | + -- --+-------------+--------+-------+---------------+---------+---------+------+------+-------+ | 1 | SIMPLE | person | index | NULL | PRIMARY | 4 | NULL | 8 | | + -- --+-------------+--------+-------+---------------+---------+---------+------+------+-------+ 如果我们用聚合主键进行排序,则Extra 为null,我们知道在innodb引擎中,主键为聚合索引,插入数据就会排好顺序.最后说明mysql是按照表内的索引顺序进行读的再看下面的列子: mysql > EXPLAIN select * from person ORDER BY salary; + -- --+-------------+--------+------+---------------+------+---------+------+------+----------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | + -- --+-------------+--------+------+---------------+------+---------+------+------+----------------+ | 1 | SIMPLE | person | ALL | NULL | NULL | NULL | NULL | 8 | Using filesort | + -- --+-------------+--------+------+---------------+------+---------+------+------+----------------+ 我们使用非主键字段进行排序,这是mysql就不能按照表内的索引顺序进行读了.需要读取数据行后再进行排序处理
　10.6 using where: 表示 MySQL 服务器从存储引擎收到查询数据,再进行“后过滤”（Post-filter）。所谓“后过滤”,就是先读取整行数据,再检查此行是否符合 where 句的条件,符合就留下,不符合便丢弃。因为检查是在读取行后才进行的,所以称为“后过滤”。
建表及插入数据： create table a16 (num_a int not null , num_b int not null , key (num_a)); insert into a16 value( 1 , 1 ),( 1 , 2 ),( 2 , 1 ),( 2 , 2 ); mysql > explain select * from a16 where num_a = 1 ; + -- --+-------------+-------+------------+------+---------------+-------+---------+-------+------+----------+-------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | Extra | + -- --+-------------+-------+------------+------+---------------+-------+---------+-------+------+----------+-------+ | 1 | SIMPLE | a16 | NULL | ref | num_a | num_a | 4 | const | 2 | NULL | + -- --+-------------+-------+------------+------+---------------+-------+---------+-------+------+----------+-------+ 虽然查询中有 where 子句,但只有 num_a = 1 一个条件,且 num_a 列存在索引,通过索引便能确定返回的行,无需进行“后过滤”。所以,并非带 WHERE 子句就会显示"Using where "的。 mysql > explain select * from a16 where num_a = 1 and num_b = 1 ; + -- --+-------------+-------+------------+------+---------------+-------+---------+-------+------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | Extra | + -- --+-------------+-------+------------+------+---------------+-------+---------+-------+------+----------+-------------+ | 1 | SIMPLE | a16 | NULL | ref | num_a | num_a | 4 | const | 2 | Using where | + -- --+-------------+-------+------------+------+---------------+-------+---------+-------+------+----------+-------------+ 此查询增加了条件 num_b = 1 ,此列没有索引,但可以看到查询同样能使用 num_a 索引。 MySQL 先通过索引 num_a 找到 num_a = 1 的行,然后读取整行数据, 再检查 num_b 是否等于 1 ,执行过程看上去象这样： num_a索引 | num_b 没有索引,属于行数据 + -- -----+-------+ | num_a | num_b | where 子句(num_b = 1 ) + -- -----+-------+ | 1 | 1 | 符合 | 1 | 2 | 不符合 | ... | ... | ... + -- -----+-------+

详情参考官方文档: https://dev.mysql.com/doc/refman/5.6/en/using-explain.html
十二. EXPLAIN结果中哪些信息要引起关注们使用EXPLAIN解析SQL执行计划时,如果有下面几种情况,就需要特别关注下了：
　　首先看下 type 这列的结果,如果有类型是 ALL 时,表示预计会进行全表扫描（full table scan）。通常全表扫描的代价是比较大的,建议创建适当的索引,通过索引检索避免全表扫描。
　　再来看下 Extra 列的结果,如果有出现 Using temporary 或者 Using filesort 则要多加关注：
　　Using temporary ,表示需要创建临时表以满足需求,通常是因为GROUP BY的列没有索引,或者GROUP BY和ORDER BY的列不一样,也需要创建临时表,建议添加适当的索引。
　　Using filesort ,表示无法利用索引完成排序,也有可能是因为多表连接时,排序字段不是驱动表中的字段,因此也没办法利用索引完成排序,建议添加适当的索引。
　　Using where ,通常是因为全表扫描或全索引扫描时（ type 列显示为 ALL 或 index ）,又加上了WHERE条件,建议添加适当的索引。
其他状态例如：Using index、Using index condition、Using index for group-by 则都还好,不用紧张。

数据库

2019-05-05 13:46:00

直面PHP微服务架构挑战

「深度学习福利」大神带你进阶工程师,立即查看>>> 在4月20日的阿里云栖开发者沙龙PHP技术专场上,云智慧Technical VP高驰涛为大家介绍了微服务的前世今生,分享了微服务架构实践中所面对的诸多挑战以及相应的应对策略。
本次直播视频精彩回顾,戳这里！
直播回顾： https://yq.aliyun.com/live/965
PPT分享： https://yq.aliyun.com/download/3527
以下内容根据演讲视频以及PPT整理而成。
专家简介
高驰涛 (Neeke Gao), 云智慧Technical VP,PHP/PECL开发组成员,具有10余年研发管理经验,同时也是PECL/SeasLog、PECL/JsonNet、GoCrab等多项开源软件的作者。2014年加入云智慧,致力于APM与大数据产品的架构研发,崇尚敏捷、高效。
从一个问题谈起
首先,从几年之前某CTO的一个问题谈起,这个问题是“我们的系统将会拥有五千个微服务组件。我们应该怎么做？”大家可以仔细思考这个问题,我们都知道一个接口肯定无法称之为微服务,达到十几个接口或许才能够叫做微服务。那么,对于包含五千个微服务的系统而言,又该怎么实现和管理呢？其实,这样的系统背后会存在很大的问题。
本次分享将会主要围绕以下三个方面内容展开：微服务的前世今生微服务的挑战应该怎么面对
微服务的前世今生
下图所展现的内容其实可以说是供大家在茶余饭后聊天的谈资,如果想要知道微服务是如何诞生的,那么就必须要了解以下四个领域的知识。
TOGAF：全称为“开放组体系结构框架”,TOGAF在上世纪七、八十年代的时候就已经由专门组织负责开发了,但一直到1995年的时候,美国国防部参与之后,TOGAF才最终成型。举例而言,大家手机里正在使用的产品和应用中,很多都会用到SAP、IBM或者惠普等的软件,而这些软件公司所遵循的就是TOGAF。可以说目前全球超过50%的企业正在使用TOGAF实践软件架构设计和开发。TOGAF是一个架构体系,而并没有提供具体的架构方法。TOGAF包含了业务架构、应用架构、数据架构、技术架构等,其实,阿里云的全局组件也属于TOGAF中的技术架构领域,其能够帮助客户减少各种繁杂的思考,使得客户只需要关注于业务架构即可。
TOGAF有三个最为主要支柱：
1)企业架构域,主要是企业信息与业务流等；
2）ADM一系列的架构方法论；
3）企业连续性,指的是在企业业务高速增长并且也不断变更的过程中,保证架构体系的连续性。
DDD：全称为“领域驱动设计”,其包含了诸多的概念,但是大家只需要记住主要的三句话即可。
1）DDD是精简的业务,DDD首先关注的就是业务,把各种繁琐的业务流程精简成更细的链条；
2）DDD需要回答业务是干什么的,能够满足什么需求,达成什么目的；
3）不断迭代,DDD的不断迭代与TOGAF的企业连续性类似。
SOA：全称为“面向服务架构”,其理论也非常多,但是大家也只需要记住三点。
1）SOA解决了信息孤岛的问题,不让信息变成孤岛；
2）业务重用,从业务角度将各个服务组合成一个个中间件或者服务,将其提供给用户或者其他系统；
3）SOA使得系统成为互联互通的信息群。
GRASP原则：全称为“通用职责分配原则”,其实很多大家耳熟能详的概念如“低耦合”、“高内聚”都来自于GRASP原则。其与设计模式不同,设计模式指导如何实现系统,而GRASP指导如何划分。GRASP原则指导定义业务架构以及API等相关内容和划分服务,其理论内容也非常多,但是只需要记住三个关键：
1）自己干自己的事；
2）自己只干自己能干的事；
3）自己只干自己的事,强调了资源划分。
在软件工程的教科书上给出了微服务架构的定义：微服务架构是一种架构模式,它提介将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为⽤户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP协议的RESTFul API)。每个服务都围绕着具体业务进⾏构建,并且能够被独⽴的部署到⽣产环境、类⽣产环境等。另外,应当尽量避免统一的、集中式的服务管理机制,对具体的一个服务⽽言,应根据业务上下⽂,选择合适的语言、工具对其进行构建。而这些教科书上的内容或许在当下来看已经过时了。
微服务带来的优势
那么,我们使用微服务架构的时候,到底得到了什么东西呢？其实得到了很多,这里为大家总结了四点最为明显的优点。
1）使得开发和迭代变得更加敏捷,使用微服务架构使得敏捷开发成为可能；
2）易于扩展和收缩,一些公司基于Kubernetes、Docker等技术可以在几秒内拉起上万个微服务,当大型流量冲击到达的时候,可以实现无损地承担全部流量,同时实现用户无感知,而当数据访问量降低之后,又可以实现快速缩容；
3）多技术栈可能,目前智慧云的技术栈非常全面,虽然开发人员只有60多人,但是开发语言却多达10多门,而使用微服务可以有效地组织各类开发人员；
4）高可修改性,比如实现数据库的快速迁移,通道的快速切换等。
微服务带来的两点疑问
这里再提出两个问题,虽然微服务能够带来诸多优点,但是也存在两点疑问。第一个就是“微服务架构,你的系统变得更健壮了吗？”；第二个则是“使用微服务让系统变得更快了吗？”对于这两点而言,可能说是见仁见智的。有人说因为组件变得越来越多,可监控性就会变难,因此系统健壮性就会变得越来越差,也有人说因为将系统拆分得越来越细,因此健壮性就会越来越强。如果单体架构是串行的,那么使用微服务可以将其变成并行的和分布式的,而多个组件之间进行通信,也会使得通信成为性能瓶颈,那么使用微服务到底是变快了还是变慢了呢？这两个问题都很难以回答。而作为一个架构师或者开发者需要进行深入的思考。
微服务架构面临的挑战和思考
这里为大家总结了在使用微服务架构的时候所需要面临的8条挑战和相关的思考。
1. 小即是多
当业务从大变小的时候,也意味着业务变多了。由大变小,可以使系统变得更加容易维护和修改,但是由少变多,又会使得问题更加复杂,因此也会有很多的挑战。第一个问题就是多节点、多服务和多状态。系统中的节点、组件服务变得更多了,那么节点和服务之间的状态也会变得更难维护,更加复杂。基于前面提到的四种知识,其实可以将从大变小和从少变多这两个转变进行折中,使得其变得更加可控。而解决这个问题的关键在于对于服务的合理拆分,主要有三点可以考虑,即数据资源、业务功能以及服务对象。
2. 债务管理
比如Bug、代码缺陷、未完成的功能或者版本不兼容等问题都是债务。当服务变得越来越多的时候,债务往往就会变得更多。为了解决这些问题,其实有这样的几种策略,比如单元测试,如果单元测试做的足够好,那么代码缺陷的可能性就会变得更低一些,可以将服务由少变多所造成的债务变多情况进行收敛；集成回归,这部分提供了很多工具去做这件事情,不用开发者自己去做；版本管理,这里指的是静态库的版本管理,动态库指的是正在变更中的库,而静态库指的是不再变更的库和配置项,这一点控制不好,就容易使得系统管理混乱；迭代冲刺,这是一种组织方式,当有很多技术债务需要进行管理时,如何将这些债务一点点处理掉或者把发散的趋势收敛住,迭代冲刺就是一种做法；Bug Crash,这是智慧云团队自己发明的一个名词,相当于是对于Bug的大扫除,无论采用传统的还是敏捷的开发模式,都有一些Bug存在,因此定期会组织全体开发和测试以及产品将自己的产品用一遍,进行Bug大扫除；回归总结,无论采用什么开发模式,在一个迭代周期完成之后,回归总结是少不了的,也需要通过一些方法解决新发生的问题,或者将其封闭住不使债务继续蔓延。
3. 复杂的服务依赖
如果只有一个或者几个组件,那么其实不存在服务依赖问题,而如果有几千个组件,那么服务依赖将会成为巨大的问题。举例而言,如果用户服务需要调用订单服务,那么在启动的时候需要进行一些初始化任务,那么一个服务的版本发布可能导致系统全面瘫痪,这就是复杂服务依赖问题。为了解决这个问题首先就需要服务发现机制,比如使用etcd或者Zookeeper等,首先服务发现中心也需要是分布式高可靠的,那么服务起来之后需要把自己的名字和调用方式告诉服务发现中心,注册上去,对于服务调用者而言只需要从服务发现中心那里通过约定好的名字获取服务调用地址即可。依赖唤醒是有一个相对比较新的东西,比如大流量突然打进来的时候,A服务需要从原来的10个启动到100个,而B从原来的3个肯定也是不够用的,因此需要通过唤醒的机制将服务拉起来,而不是被动的被通知。还有一种情况也需要使用到依赖唤醒机制,比如缓存穿透问题,正常情况下,缓存是生效的,不会存在穿透的情况,但是可能因为某种异常使得缓存不生效了,会将大量的流量打到DB里面去,使得服务变得不可用了,整个服务雪崩掉,针对这些问题一般会开发一些挡板服务,可能会给出一些固定的数据,而这些挡板服务也有可能会面临这种突发的流量也需要通过依赖唤醒的机制实现唤醒。此外,还有灰度发布和AB测试,这两点是相关联的。还有多版本共存问题,对于服务的多版本也是一个技术债务问题,需要考虑如何将其旧版本拿下来。
4. 消息通讯
如果系统中包含多个语言栈,多种实现方式。那么统一标准是必须的,要么统一一种RPC或者就使用RestFul API等。消息中心也是一种处理做法,这一点在Java中应用很多,消息中心并不是消息队列,而是一个事件驱动的消息中心。此外,还有通讯网关,这在使用微服务的时候也是一个必要点,其主要解决了监控问题,而且可以通过网关起到中控的作用,比如安全、性能以及用户校验等任务。
5. 分布式事务
在实现分布式事务的时候可以采用2PC或者3PC原则来实现,2PC原则是通过全部节点投票和执行两个步骤完成的,并且是阻塞的；而3PC则不同,虽然在一个具体的事务里面可以是阻塞的,也可以是非阻塞的。3PC协议则是通过“Can-Pre-Do”三个步骤来实现的,其实PDU就是3PC协议在单体中的实现方式。而在分布式系统中,3PC有三种实现方式,使用分布式的事件驱动、最大通知以及两阶段补偿TCC。
6. 花式故障
很多时候,当系统出现问题可能需要花费数周和很多人力才能找到根源所在,可能因为系统太多,使得系统架构师也无法清楚系统与系统之间的关系。面对诸多的花式故障,也有多种策略可以应对,比如全链路追踪,比如使用Open Tracking；主动拨测,很多用户端的APP里面内置探针,使其可以接收Server端的指令来定期探测接口和服务是否正常。
7. 中心与去中心
中心与去中心可以算是一个永恒的话题,上图中展示的配置、发号、日志、调度、状态以及预警,其实对于比较成熟的大型系统而言,这六点都是需要中心的。
8. 组织危机
最后一个问题,也是最大的问题。其实要实现向微服务架构的变更的时候,最大的问题就是组织危机。这一点与开发者关系不大,但是对于Team Leader以及组织的管理人员而言,关系就非常大了。架构的转变需要考虑到信任危机、过期维护、多语言栈、沟通协作、安全网关以及轮岗结对等问题。
总结
总结而言,最重要的观点有两个：微服务不是银弹。不要让重复的事情做两次。
作者：PHP小能手
原文链接
本文为云栖社区原创内容,未经允许不得转载。

数据库

2019-05-05 13:03:00

深入浅出网络编程与Swoole内核

「深度学习福利」大神带你进阶工程师,立即查看>>>
摘要：在阿里云PHP技术沙龙专场中,阿里云邀请到php-nsq作者,pecl、Swoole开发组成员吴振宇分享了Swoole进程模型的原理与Swoole协程实现的原理。并结合具体开发案例讲解了Swoole在网络编程中的应用。
本次直播视频精彩回顾,戳这里！
直播回顾： https://yq.aliyun.com/live/965
PPT分享： https://yq.aliyun.com/download/3528
以下内容根据演讲嘉宾视频分享以及PPT整理而成。
Socket编程
网络编程又可称为Socket编程。编程分为基于Server端开发与基于Client端开发两部分。基于Server端的编程由四大步骤组成,开发者首先创建Socket,利用bind与listen函数绑定监听地址及相应的端口,最后使用accept函数接受来自监听端的请求。Client端的操作较为简便,开发者在创建Socket后使用connect函数对服务器端进行连接即可实现。
下图所示为Client端与Server端的协作示意图。Client端首先向Server端发起带有SYN标识的握手请求,Server端接受到请求后,返回给Client端带有SYN与ACK标识的请求并将Client端中的RCVD文件加载至队列中,在三次握手完成之后,该文件描述符将被添加至accept队列中等待下一步逻辑处理。
下图所示为Socket编程的实现代码
在Socket编程中,Socket的读写状态判断十分重要。Socket可读条件分为以下四条：该套接字接收缓冲区中的数据字节数大于等于套接字接收缓存区低水位。该连接的读半部关闭（也就是接收了FIN的TCP连接）。有新链接到达可读,该套接字是一个listen的监听套接字,并且目前已经完成的连接数不为0。有一个Socket有异常错误条件待处理.对于这样的Socket读操作将不会阻塞,并且返回一个错误(-1),errno则设置成明确的错误条件。
以上条件中,第一条件与第三条件较为重要。对于TCP和UDP套接字而言,缓冲区低水位的值默认为1,在默认情况下,缓冲区中的数据均为可读。当为Socket收到connect请求,执行了三次握手的第一步接收SYN请求后,Socket便处于可读状态。对这样的套接字进行accept操作通常不会阻塞。
对应于Socket可读条件的判断,Socket可写条件也分为以下四条：该套接字发送缓冲区中的可用空间字节数大于等于套接字发送缓存区低水位标记时,并且该套接字已经成功连接。该连接的写半部关闭。使用非阻塞的connect套接字已建立连接,或者connect已经以失败告终。有一个错误的套接字待处理。
下图举了生活中与网络阻塞类似的生活事例来展示该过程。在用户到手机店修手机的过程中,用户在手机店不做任何事,等待老板将手机修好类似于网络同步阻塞过程；用户在店中做些其他工作,不时询问老板手机是否修好类似于同步非阻塞过程；用户回到家中,等待手机店老板修好后的电话类似于异步阻塞过程；用户回到家中做其他事情,等待老板修好后的电话类似于多路IO 复用、异步非阻塞过程。
在一款应用开发初期,应用的用户不多,服务器相对的要求同样不高,此时开发者可以使用多进程策略进行应用的开发,以此加快开发效率。下图所示为多进程同步阻塞开发的伪代码。
当业务量扩大,系统需要进行优化时,开发者可以对每个子进程中的套接字进行监听,其伪代码如下图所示。
IO复用与Reactor
当系统的用户及业务量扩大到一定规模时,开发者可以使用多路IO复用、Reactor及异步非阻塞等方法对系统进行改进。如下图所示,在这些系统调用中,Select方法存在内存开销大,支持文件描述符数量少的缺点。目前Epoll系统调用方式占据开发的主流位置,Epoll方式采用了红黑树的数据结构模式,同时拥有就绪列表rdlist,当套接字中存在可读或可写的事件时,该事件将被直接添加到就绪列表当中,从而使系统省去了轮询所有套接字属性的过程,提高了系统的执行效率。
（1）操作系统调度原理
操作系统进程调用时分为正在运行,阻塞运行及等待运行三个状态。在处理进程的过程中,内核会不断发生中断,比如三次握手过程中,当ACK发送时,内核会触发中断,系统此时需要放下正在执行的任务,去处理TCP的任务。处理完成后,系统结束中断处理并恢复运行被打断的进程。下图所示为操作系统进程调度的一些方法。
在三次握手中,系统执行以下三个步骤完成操作系统的调度：
1.网卡收到数据：网卡收到SYN消息,触发内核中断,系统将直接打断当前执行的进程,同时CPU将会把套接字加入到Socket Queue队列当中进行存储。
2.中断回调：若当前没有新的连接,accept将阻塞到系统调用上,并将套接字注册到Wait Queue上。
3.系统中断回调：当新的连接产生时,Wait Queue队列将触发回调函数,将相应数据加载至rdlist列表中。
若网卡收到ACK消息,则继续触发内核中断,内核完成标准的三次握手,将连接从半连接队列移入连接队列,于是 listen Socket有可读事件,内核调用listen Socket的Wait Queue的唤醒回调函数,将之前阻塞的accept进程置为 Ready调度状态。
（2）Epoll的在调度中的作用
Epoll主要用来监听Socket的可读可写过程,在Epoll创建时,开发者需要传对应文件描述符EPOLLIN与EPOLLOUT作为可读与可写的参数标志,epoll_wait函数拥有accept的功能,会在事件发送后提醒开发者。下图罗列了Epoll中的参数与主要方法。
将Socket创建与accept过程转化为Epoll的代码示意图如下所示。首先将fd作为描述符加入创建好的Epoll中,同时把开发者想要监听的可读可写事件也注册入Epoll之中。当listen fd监听到事件时,使用accept方法将该fd描述符设为可读事件,并再次将其加入到Epoll的监听数组中,此时代表真正的客户端连接已接入。

Swoole进程模型与Reactor
Reactor模型的创建与使用较为简单,其中含有以下四个方法： Add方法：添加一个Socket到Reactor之中。 Set方法：修改Socket对应的事件,如可读可写事件等。 Del方法：从Reactor中移除相应的对象。 Callback方法：事件发生后回调指定的函数方法。
Swoole目前使用较多的模式为单线程模式与进程模式。在单线程模式中,系统使用Worker监听accept与链接,当Worker挂掉后会对系统产生一些影响。进程模式的Swoole解决了这些问题。下图为两种模式的详细对比。
在进程模式中,系统采用MainReactor线程监听accept,线程将出现的问题抛给Worker进程进行处理,这样即使单个Worker进程挂掉也不会对系统产生任何的影响。下图所示为进程模式的系统结构示意图。
下图展示了对Swoole模式的调用代码示意。在用户使用客户端去连接服务器的过程中,系统首先注册可读可写与超时三个状态回调函数。客户端与服务器连接成功时,套接字变为可写状态,系统调用可写状态的回调函数,在回调函数中处理相关的数据。

Swoole协程实现原理
Swoole协程是由事件驱动与栈切换两步共同实现完成的。
在C语言环境中,事件的调用往往使用堆栈进行处理。在堆栈中,指针EBP指向堆栈栈底,指针ESP指向堆栈栈顶,在函数调用之后,每个EBP的返回值会返回上一个EBP的地址。以此来进行事件调用的检索。下图所示为C语言中的事件调用示意图。

在PHP中的函数调用步骤如下图所示。PHP首先通过词法分析与语法分析将代码编译成语法树,语法树中的每一个语法会被编译入opcode,语法中的每一个函数会以oparray的形式存入结构体EG中,EG结构体使用函数表对这些函数进行存储。
当函数调用时,结构体中的call对应指针ESP,prev对应于指针EBP。当用户调取函数时,系统会向zend VM中为每一个方法申请一个堆栈的内存。当系统中一个函数调用其他函数时,会调用code下方储存的地址,调用方法的opcode从function存储的成员中找到并进行编译与执行。当触发了opcode后,系统会申请一个新的内存来进行新的内存分配。下图为PHP调用示意图。
下图所示为在PHP函数调用中压栈的过程及函数中存在的opcode。FCALL与DO_FCALL负责函数的调用,当堆栈中第一个opcode执行时,将进行参数压栈的操作。触发函数调用时,将执行DO_FCALL操作,系统将会把下一个函数的调用地址压入堆栈。当调用有结果后系统会将返回值返回入CALL FRAME中。

下图所示为Swoole协程代码。协程代码包括两个执行网络IO操作的go函数,当系统执行connect操作时触发网络IO操作,并将当前的PHP调用栈先保存起来。在当前调用栈保存好后,系统顺次执行下面的函数调用。当connect遇到IO函数时,系统会跳出当前任务去执行堆栈中储存的任务。
在Swoole2.0中使用C函数进行线程任务的协程。当开发者调用setjmp时,函数的返回值为0并调起first函数。当调用longjmp时,setjmp也同样被调起,此时返回值为1。Swoole2.0利用该代码实现了PHP执行的跳转,代码示意图如下。
Swoole2.0协程时序图与代码展示如下图所示。setjump方法设置当前函数堆栈,当有网络事件产生时,系统将首先对产生的事件进行注册,并在有事件通知时跳回执行中的代码,以此完成代码协程过程。

Swoole4.0通过实现C堆栈对Swoole2.0中的问题进行了改进。在Swoole4.0中用户直接调用MySQL中的链接直接就可以形成网络协程。下图所示为Swoole4.0内核系统架构示意图。
Swoole4.0的时序调度与Swoole2.0差别不大,不同的是Swoole4.0使用汇编指令对C栈与堆栈进行了存储。在协程创建时,系统会产生C栈与PHP栈,两个堆栈间会进行通信,通过这种方法解决了C栈销毁后的一些问题。下图展现了Swoole4.0的时序图。
当系统链接数量增多后会出现一些问题,开发者通过设置心跳参数与心跳收回可以保证系统服务器的资源不会被浪费。下图列举了Swoole网络编程对系统进行优化的方式。

总结
下图为吴老师分享的内容的关键词总结。
作者：PHP小能手
原文链接
本文为云栖社区原创内容,未经允许不得转载。

数据库

2019-05-05 12:37:00

RabbitMQ 的延时队列和镜像队列原理与实战

「深度学习福利」大神带你进阶工程师,立即查看>>>
摘要：在阿里云栖开发者沙龙PHP技术专场上,掌阅资深后端工程师、掘金小测《Redis深度历险》作者钱文品为大家介绍了RabbitMQ的延时队列和镜像队列的原理与实践,重点比较了RabbitMQ提供的消息可靠与不可靠模式,同时介绍了生产环境下如何使用RabbitMQ实现集群间消息传输。
本次直播视频精彩回顾,戳这里！
直播回顾： https://yq.aliyun.com/live/965
PPT分享： https://yq.aliyun.com/download/3529
本文根据演讲视频以及PPT整理而成。
本文将主要围绕以下四个方面进行分享： RabbitMQ特性 RabbitMQ中的消息不可靠问题及其解决方案死信队列生产环境下使用RabbitMQ应注意的事项
RabbitMQ特性
对于左边的Client Publisher而言,RabbitMQ Server是消息的接收者,也就是消费者;对于右边的Client Consumer而言,RabbitMQ Server是消息的发送者,也就是生产者。RabbitMQ Server将消息从Client Publisher传送给Client Consumer,扮演着消息中间商的角色。
RabbitMQ Server负责将Client Publisher传递来的消息持久化,延后地将消息传递给Client Consumer.这样,即使消费者挂掉,RabbitMQ Server也可以存储消息,当消费者重新工作时再将存储的消息传递过去,从而保证消息不丢失。RabbitMQ Server提供了堆积消息的能力。

另外,RabbitMQ Server还具有复制和广播消息的能力。具体来说,RabbitMQ Server可以将Client Publisher发布的消息分发给多个消费者,比如它能够将特定的消息按照特定的队列分发给特定的消费者。“特定”指不同消息具有不同的routing key属性,由上图实例,不同的消息生产者生产了具有不同routing key的消息,通过exchange路由器将不同的routing key消息投递到不同队列,从而分发给不同消费者。
RabbitMQ中的消息不可靠问题及其解决方案
消费端消息不可靠问题及其解决方案
实际上,RabbitMQ Server将消息投递给消费者,具有消息不可靠的特点。具体来说,RabbitMQ Server将消息投递给消费者时会调用套接字的write操作,而write操作的过程是不可靠性的。在write操作的过程中,Server需要将消息发送到套接字的缓存中,通过网卡转发到链路上,最终到达消费者所在的机器内核的套接字缓存中,由消费者使用套接字的read操作将消息读出来。
即使套接字的write操作成功也无法保证消息可靠,潜在的网络故障可能使消费者接收不到消息。机器宕机也可能使消息不可靠,即使消息字节流已经到达消费者所在机器,消费者所在机器的宕机也可能使消息无法被即时读取并处理。另外,即使消费者即时读取消息,内存消息队列中的所有消息也可能因为kill-9操作发生丢失。这些可能性都直接导致了消息不可靠。
因此,需要额外的措施为消息提供可靠保障。一种消息可靠性保障方式是,Server投递消息后并不立即将消息从Server删除,而是等到消费者接收、处理消息并返回Ack包给Server后,Server才删除该消息。如果消费者没有发送Ack包,那么Server将重新投递该消息。这个过程确保消息被消费者处理,保证了消息可靠。另外,假如消费者已处理消息并发送Ack包给Server,但由于网络故障等问题导致Ack包丢失时,那么Server同样会重新投递该消息,导致消息被重复处理。消息的重复处理通常由业务层面的技术手段来避免,比如在数据库层面添加主键约束等。另一种重复消息处理的避免方式是客户端对每条消息维护ID, 将被处理消息的ID记录在列表中,同时检查新到消息是否在该列表中。
RabbitMQ中的Auto Ack和Manual Ack对应着消息不可靠模式和消息可靠模式. Auto Ack即no ack,指消息投后即删除,对应消息不可靠传输。Manual Ack即手动Ack,消费者处理完消息后使用Ack包通知Server删除消息,对应消息可靠传输。
Auto Ack是RabbitMQ中最常用的模式,性能较好,但具有以下问题。当消息通过套接字write操作投递后,RabbitMQ Server立即删除该消息,该模式在遇到网络故障时容易发生消息丢失。另外,假如消费者处理消息的速率过低,可能导致消息在消费者recv buffer中大量堆积,从而导致Server端send buffer也堆积大量消息, Server端无法继续调用套接字write操作。这样,一段时间之后,Server可能强制关闭消息传输链接,导致消息不可传输。
尽管Auto Ack存在一定风险,目前许多公司仍在应用Auto Ack模式。使用Auto Ack模式时,开发者需要注意消费者和生产者的实例数量比例,使消息生产者产生消息的速率与消费者消费消息的速率大致持平。
Manual Ack是RabbitMQ 中更加智能的一种模式。Manual Ack在工作时会考虑消息消费者的消息接收能力,根据消费者的消息接受能力和当前接收到的Ack包自动调节分发消息的速率,保证消息分发可靠、不阻塞。具体来说,客户端通过PrefetchCount告知Server自身堆积消息的能力。
生产端消息不可靠问题及其解决方案
消息生产端同样存在消息的可靠性问题。从Client Publisher将消息传递给Server和从Server将消息传递给Client Consumer的过程是完全对等的,Server和Client Consumer间传递消息的可靠性问题在Client Publisher和Server间同样存在。
Client Publisher首先将消息写到套接字,再通过网络传递给Server的套接字buffer,最终由Server读取该消息。这一过程的潜在网络问题也可能使Server端接收不到消息。
另外,Server端本身也可能导致消息不可靠。Server端需要持久化消息,但出于性能开销的考虑,Server端并不在每次持久化消息时都刷盘。具体来说,Server端会对文件执行write操作,将脏数据写入操作系统的缓存中,而不是立即将数据写入磁盘。一般情况下,Server可能每几百毫秒执行一次fsync操作,通过fsync操作将文件的脏数据写入磁盘。由于Server具有宕机风险,那么每次Server宕机时,还未被fsync操作处理的数据就可能丢失,此过程类似于Redis AOF。
RabbitMQ通过生产者事务和生产者确认两个方法解决Server产生的数据不可靠问题。
生产者事务的基本原理是采用select和commit指令包裹publish,在消息生产者publish数据之前执行select操作,相当于begin transaction事务开始,在执行若干个publish操作后,再执行commit操作,相当于提交事务。根据tcp包的有序性,commit包成功接收意味着commit包之前的包也成功接收。因此,收到从Client Publisher传递过来的commit包意味着该commit包之前的所有publish包都已成功接收,即所有消息都成功接收。然而,commit包只有等到Server端的fsync操作执行完毕时才返回,因此生产者事务的效率较低,通常只在有批量publish操作时才使用生产者事务模式。也就是说,客户端将消息累计起来批量发送,以降低fsync操作带来的性能损失。此外,在进程中累计消息也存在风险,累计的消息可能由于进程挂掉而丢失。总的来说,生产者事务由于性能缺点不被RabbitMQ官方推荐。
另一种Server带来的数据不可靠问题的解决方案是生产者确认。生产者确认类似于消费端的Ack机制,生产者可能连续发送多条消息,Server将这些消息异步地通过fsync操作写入磁盘再异步地给生产者发送Ack包,告知生产者消息的接收成功。由于Ack包异步传输,不影响生产者端消息的正常发送。生产者确认模式下,Ack包批量发送,并且都携带有序号,以告知生产者该序号以前的所有消息都已正常落盘。尽管RabbitMQ推荐用户使用生产者确认模式,目前的RabbitMQ版本还未实现消息的重发机制,只实现了Ack包的批量发送,以通知Client Publisher哪些消息接收成功。当消息丢失时,Client Publisher端已publish的消息在进程挂掉时也可能丢失,而不是重新发送,因此生产者确认的作用也不明显。当然,生产者确认起到了降低消息发布速度的作用,减小了消息丢失的数量。
生产者确认中的消息重发可以通过以下几种方法实现。第一种方式在内存中累积还未收到Ack包的消息,收到Ack包后删除该消息,对于一段时间内还停留在内存中的消息,重发该消息。这种方式将未Ack消息存入内存,一旦消息生产者宕机,这些消息也会丢失。另一种方式将未收到Ack包消息存入磁盘,当收到Ack包后删除该消息,然而,磁盘存储依赖于fsync操作,降低了系统处理消息的性能。同时,这还会提高编程的复杂度,因为这要求发布消息时维护文件队列,还要求一个异步线程将文件队列中的消息发布到Server,带来了多线程和锁问题。还有一种方式将未Ack消息存入Redis,但当出现网络故障时,Redis也是不可靠的。目前提供的生产者确认中的消息重发方案都还存在问题,具体的方案选择依赖于实际场景和个人取舍。
死信队列
生产者确认中的消息重发可以通过以下几种方法实现。第一种方式在内存中累积还未收到Ack包的消息,收到Ack包后删除该消息,对于一段时间内还停留在内存中的消息,重发该消息。这种方式将未Ack消息存入内存,一旦消息生产者宕机,这些消息也会丢失。另一种方式将未收到Ack包消息存入磁盘,当收到Ack包后删除该消息,然而,磁盘存储依赖于fsync操作,降低了系统处理消息的性能。同时,这还会提高编程的复杂度,因为这要求发布消息时维护文件队列,还要求一个异步线程将文件队列中的消息发布到Server,带来了多线程和锁问题。还有一种方式将未Ack消息存入Redis,但当出现网络故障时,Redis也是不可靠的。目前提供的生产者确认中的消息重发方案都还存在问题,具体的方案选择依赖于实际场景和个人取舍。
三、死信队列
死信队列使用了RabbitMQ中的一种特殊队列属性,即x-message-ttl属性,表示队列中消息的构建时间。假如用户在声明队列时定义队列的x-message-ttl属性,此后所有进入该队列的消息都将持有构建时间,到达构建时间的消息将被删除。如果还为队列配置了回收站属性,那么即使构建时间到达,RabbitMQ也不会立即删除这些消息,而是将这些过期消息丢入回收站,即死信队列。
死信队列的工作方式如上图。Client Publisher将消息投递给路由器,也就是exchange,再由exchange将消息投递给队列,由队列生成该消息的构建时间,到达构建时间的消息将过期,同时进入死信队列。过期消息进入死信队列的方式和进入普通队列的方式基本一致,即先投递给exchange路由器,再由exchange投递消息。消费者消费死信队列,得到的消息是延后的消息,延迟的时间长度即构建时间。目前,死信队列存在的问题是,一个队列只能设置一个构建时间,消息的过期时间不够灵活,不能满足一些特殊场景的需求,比如动态的重试时间。
死信队列的另一个使用场景是Retry Later,即在一段时间后才重新处理此前处理失败的消息,这时可能用到双重死信。具体来说,死信队列不仅可以接收过期消息,还可以接收被reject的消息,即消费端拒绝处理或处理过程发生异常的消息,Reject操作具有requeue参数,当requeue设为true时被reject消息会重新进入消息队列并被重新投递,当requeue设为false时被reject消息将进入死信队列。假如死信队列持有构建时间,那么到达构建消息的消息将重新投递给原有队列,实现Retry Later。双重死信在使用过程中需注意消息处理的死循环问题,因为消息可能无限循环地进入死信队列。
生产环境下使用RabbitMQ应注意的事项
生产环境下,RabbitMQ通过使用集群模式。集群模式下,只有元信息分布在所有节点中。元信息指队列信息,路由器信息等,队列中的信息只存储在一个节点中,因此,单个节点宕机会导致所有节点都不可用。另外,RabbitMQ的所有节点间存在转发机制,即允许节点转发其他目标节点的消息处理请求,这样客户端只需连接到任意一个节点就可以实现其消息转发需求。
队列的高可用依赖于RabbitMQ的镜像队列,即在其他节点上备份某节点的消息内容。这样,当消息所在主节点宕机时,其他镜像节点可以替代主节点完成消息传递任务。
通常情况下,镜像节点是默默无闻的,客户端无需感知镜像节点的存在。只有当主节点宕机时,镜像节点才发挥作用。镜像队列的配置如下： Ha-mode具有三个选项,all指将所有队列的信息存入所有节点,这种模式最安全,但也最浪费存储空间；exactly指由用户精确指定每个队列的复制数,当ha-mode设置为exactly,ha-params设置为2时表示“一主一从”,这种模式是官方推荐的；nodes指由用户指定副本所在的节点,这种模式极少被使用。 x-queue-master-locator用于设置存储队列主节点的RabbitMQ节点。min-master指将队列主节点设置在队列数量最少的RabbitMQ节点,client-local指将队列主节点设置在当前客户端所在的RabbitMQ节点,random即随机选择节点。 Ha-sync-mode用于镜像节点代替宕机主节点并创建新节点以弥补缺失节点时,设置新节点上数据的同步策略。automatic指自动地将新主节点上数据全部同步给新节点,manual指不同步新主节点上的老数据,只同步新产生的数据。由于节点间数据同步需要耗费时间,长时间的数据同步可能会影响服务的稳定性,但通常情况下RabbitMQ的节点堆积的数据量并不大,因此RabbitMQ官方推荐使用Automatic进行数据同步。 Ha-sync-batch-size指节点间批量同步的数据量。 Ha-promote-on-shutdown表示主动停止主节点的服务时,其他节点如何替代主节点。Always指其他节点总是能顺利地替代主节点,when-synced要求与原主节点数据完全一致的节点才能替代主节点。 Ha-promote-on-failure表示异常情况下其他节点如何替代主节点,always和when-synced的含义与Ha-promote-on-shutdown中一致。
许多公司为RabbitMQ集群设置了内存模式,认为内存模式无需落盘,能够提升系统性能。但实际上,RabbitMQ官方文档指出,内存模式无法提升系统性能,它只提升了产生元信息数据的速度,即Ram Node指将元信息存入内存,可以提升元信息的创建速度,而不是消息数据的性能。这是使用RabbitMQ时的一个常见误区。
作者：PHP小能手
原文链接
本文为云栖社区原创内容,未经允许不得转载。

数据库

2019-05-05 12:01:00

Redis闲谈（1）：构建知识图谱

「深度学习福利」大神带你进阶工程师,立即查看>>>
场景：Redis面试
（图片来源于网络）面试官：我看到你的简历上说你熟练使用Redis,那么你讲一下Redis是干嘛用的？
小明：（心中窃喜,Redis不就是缓存吗？）Redis主要用作缓存,通过内存高效地存储非持久化数据。
面试官： Redis可以用作持久化的存储吗？
小明：嗯...应该可以吧...
面试官：那Redis怎么进行持久化操作呢？
小明：嗯...不是太清楚。
面试官： Redis的内存淘汰机制有哪些？
小明：嗯...没了解过
面试官：我们还可以用Redis做哪些事情？分别利用了Redis的哪个指令？
小明：我只知道Redis还可以做分布式锁、消息队列...
面试官：好了,我们进入下一个话题...
思考：很明显,小明同学在面试过程中关于Redis的表现和回答肯定是比较失败的。Redis是我们工作中每天都会使用到的东西,为什么一到面试却变成了丢分项呢？
作为开发者,我们习惯了使用大神们已经封装好的东西,以此保障我们能够更专注于业务开发,却不知道这些常用工具的底层实现是什么,因此尽管平时应用起来得心应手,但一到面试还是无法让面试官眼前一亮。
本文总结了一些Redis的知识点,有原理有应用,希望可以帮助到大家。
一、Redis是什么 REmote DIctionary Server(Redis) 是一个由Salvatore Sanfilippo写的key-value存储系统。
Redis是一个开源的使用ANSI 、C语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库,并提供多种语言的API。
这里我引用了Redis教程里对Redis的描述,很官方,但是很标准。可基于内存亦可持久化的日志型、Key-Value数据库。我认为这个描述很贴切很全面。
1.1 Redis的行业地位
Redis是互联网技术领域使用最为广泛的存储中间件,因超高的性能、完美的文档、多方面的应用能力以及丰富完善的客户端支持在存储方面独当一面,广受好评,尤其以其性能和读取速度而成为了领域中最受青睐的中间件。基本上每一个软件公司都会使用Redis,其中包括很多大型互联网公司,比如京东、阿里、腾讯、github等。因此,Redis也成为了后端开发人员必不可少的技能。
1.2 知识图谱
在我看来,学习每一项技术,都需要有一个清晰的脉络和结构,不然你也不知道自己会了哪些、还有多少没学会。就像一本书,如果没有目录章节,也就失去了灵魂。
因此我试图总结出Redis的知识图谱,也称为脑图,如下图所示,可能知识点不是很全,后续会不断更新补充。
本系列文章的知识点也会和这个脑图基本一致,本文先介绍Redis的基本知识,后续文章会详细介绍Redis的数据结构、应用、持久化等多个方面。
二、Redis优点
2.1 速度快
作为缓存工具,Redis最广为人知的特点就是快,到底有多快呢？Redis单机qps（每秒的并发）可以达到110000次/s,写的速度是81000次/s。那么,Redis为什么这么快呢？绝大部分请求是纯粹的内存操作,非常快速；使用了很多查找操作都特别快的数据结构进行数据存储,Redis中的数据结构是专门设计的。如HashMap,查找、插入的时间复杂度都是O(1)；采用单线程,避免了不必要的上下文切换和竞争条件,也不存在多进程或者多线程导致的切换而消耗CPU,不用去考虑各种锁的问题,不存在加锁、释放锁操作,没有因为可能出现死锁而导致的性能消耗；用到了非阻塞I/O多路复用机制。
2.2 丰富的数据类型
Redis有5种常用的数据类型：String、List、Hash、set、zset,每种数据类型都有自己的用处。
2.3 原子性,支持事务
Redis支持事务,并且它的所有操作都是原子性的,同时Redis还支持对几个操作合并后的原子性执行。
2.4 丰富的特性
Redis具有丰富的特性,比如可以用作分布式锁；可以持久化数据；可以用作消息队列、排行榜、计数器；还支持publish/subscribe、通知、key过期等等。当我们要用中间件来解决实际问题的时候,Redis总能发挥出自己的用处。
三、Redis和Memcache对比
Memcache和Redis都是优秀的、高性能的内存数据库,一般我们说到Redis的时候,都会拿Memcache来和Redis做对比。（为什么要做对比呢？当然是要衬托出Redis有多好,没有对比,就没有伤害~）对比的方面包括：存储方式 Memcache把数据全部存在内存之中,断电后会挂掉,无法做到数据的持久化,且数据不能超过内存大小。 Redis有一部分数据存在硬盘上,可以做到数据的持久性。数据支持类型 Memcache对数据类型支持相对简单,只支持String类型的数据结构。 Redis有丰富的数据类型,包括：String、List、Hash、Set、Zset。使用的底层模型它们之间底层实现方式以及与客户端之间通信的应用协议不一样。 Redis直接自己构建了VM机制 ,因为一般的系统调用系统函数,会浪费一定的时间去移动和请求。
4）存储值大小 Redis最大可以存储1GB,而memcache只有1MB。
看到这里,会不会觉得Redis特别好,全是优点,完美无缺？其实Redis还是有很多缺点的,这些缺点平常我们该如何克服呢？
四、Redis存在的问题及解决方案
4.1 缓存数据库的双写一致性的问题
问题：一致性的问题是分布式系统中很常见的问题。一致性一般分为两种：强一致性和最终一致性,当我们要满足强一致性的时候,Redis也无法做到完美无瑕,因为数据库和缓存双写,肯定会出现不一致的情况,Redis只能保证最终一致性。
解决：我们如何保证最终一致性呢？第一种方式是给缓存设置一定的过期时间,在缓存过期之后会自动查询数据库,保证数据库和缓存的一致性。如果不设置过期时间的话,我们首先要选取正确的更新策略：先更新数据库再删除缓存。但我们删除缓存的时候也可能出现某些问题,所以需要将要删除的缓存的key放到消息队列中去,不断重试,直到删除成功为止。
4.2 缓存雪崩问题
问题：我们应该都在电影里看到过雪崩,开始很平静,然后一瞬间就开始崩塌,具有很强的毁灭性。这里也是一样的,我们执行代码的时候将很多缓存的实效时间设定成一样,接着这些缓存在同一时间都会实效,然后都会重新访问数据库更新数据,这样会导致数据库连接数过多、压力过大而崩溃。
解决：设置缓存过期时间的时候加一个随机值。设置双缓存,缓存1设置缓存时间,缓存2不设置,1过期后直接返回缓存2,并且启动一个进程去更新缓存1和2。
4.3 缓存穿透问题
问题：缓存穿透是指一些非正常用户(黑客)故意去请求缓存中不存在的数据,导致所有的请求都集中到到数据库上,从而导致数据库连接异常。
解决: 利用互斥锁。缓存失效的时候,不能直接访问数据库,而是要先获取到锁,才能去请求数据库。没得到锁,则休眠一段时间后重试。采用异步更新策略。无论key是否取到值,都直接返回。value值中维护一个缓存失效时间,缓存如果过期,异步起一个线程去读数据库,更新缓存。需要做缓存预热(项目启动前,先加载缓存)操作。提供一个能迅速判断请求是否有效的拦截机制。比如利用布隆过滤器,内部维护一系列合法有效的key,迅速判断出请求所携带的Key是否合法有效。如果不合法,则直接返回。
4.4 缓存的并发竞争问题
问题：
缓存并发竞争的问题,主要发生在多线程对某个key进行set的时候,这时会出现数据不一致的情况。
比如Redis中我们存着一个key为amount的值,它的value是100,两个线程同时都对value加100然后更新,正确的结果应该是变为300。但是两个线程拿到这个值的时候都是100,最后结果也就是200,这就导致了缓存的并发竞争问题。
解决如果多线程操作没有顺序要求的话,我们可以设置一个分布式锁,然后多个线程去争夺锁,谁先抢到锁谁就可以先执行。这个分布式锁可以用zookeeper或者Redis本身去实现。可以利用Redis的incr命令。当我们的多线程操作需要顺序的时候,我们可以设置一个消息队列,把需要的操作加到消息队列中去,严格按照队列的先后执行命令。
五、Redis的过期策略
Redis随着数据的增多,内存占用率会持续变高,我们以为一些键到达设置的删除时间就会被删除,但是时间到了,内存的占用率还是很高,这是为什么呢？
Redis采用的是定期删除和惰性删除的内存淘汰机制。
5.1 定期删除
定期删除和定时删除是有区别的：定时删除是必须严格按照设定的时间去删除缓存,这就需要我们设置一个定时器去不断地轮询所有的key,判断是否需要进行删除。但是这样的话cpu的资源会被大幅度地占据,资源的利用率变低。所以我们选择采用定期删除,。定期删除是时间由我们定,我们可以每隔100ms进行检查,但还是不能检查所有的缓存,Redis还是会卡死,只能随机地去检查一部分缓存,但是这样会有一些缓存无法在规定时间内删除。这时惰性删除就派上用场了。
5.2 惰性删除
举个简单的例子：中学的时候,平时作业太多,根本做不完,老师说下节课要讲这个卷子,你们都做完了吧？其实有很多人没做完,所以需要在下节课之前赶紧补上。
惰性删除也是这个道理,我们的这个值按理说应该没了,但是它还在,当你要获取这个key的时候,发现这个key应该过期了,赶紧删了,然后返回一个'没有这个值,已经过期了!'。
现在我们有了定期删除 + 惰性删除的过期策略,就可以高枕无忧了吗？并不是这样的,如果这个key一直不访问,那么它会一直滞留,也是不合理的,这就需要我们的内存淘汰机制了。
5.3 Redis的内存淘汰机制
Redis的内存淘汰机制一般有6种,如下图所示：
那么我们如何去配置Redis的内存淘汰机制呢？
在Redis.conf中我们可以进行配置 # maxmemory-policy allkeys-lru
六、小结
本文初探Redis,大概整理出了Redis的知识图谱,对照之下可以发现Redis居然有这么多的知识点需要学习；接着我们分析了Redis的优缺点,知道了其基于内存的高效的读写速度和丰富的数据类型,也分析了Redis面对数据一致性、缓存穿透、缓存雪崩等问题时该如何处理；最后我们了解了Redis的过期策略和缓存淘汰机制。
相信大家已经对Redis有了一些了解,下篇文章我们将分析Redis的数据结构、每一种数据类型是如何实现的、对应的命令有哪些。
作者：杨亨
来源：宜信技术学院

数据库

2019-05-05 11:07:00

MySQL 日期转换，时间转换，时间段查询

「深度学习福利」大神带你进阶工程师,立即查看>>>

时区转换转换数据库中已存时间的时区 CONVERT_TZ(dt ,from_tz ,to_tz ) eg SELECT now(), CONVERT_TZ (now(), '+8:00', '-8:00') as los; //时区转换也可以通过 date_add, date_sub, timestampadd 来实现
获得国家地区时间格式 get_format(date|time|datetime, 'eur'|'usa'|'jis'|'iso'|'internal' eg select get_format(date,'usa'); -- %m.%d.%Y select get_format(time,'usa'); -- %h:%i:%s %p select get_format(datetime,'usa'); -- %Y-%m-%d %H.%i.%s //函数使用说明： CONVERT_TZ() 将时间日期值 dt 从 from_tz 给出的时区转到 to_tz 给出的时区,然后返回结果值。关于可能指定的时区的详细论述,若自变量无效,则这个函数会返回 NULL

查询当前日期时间 select now() -- 日期+时间 select sysdate() -- 日期+时间 select current_timestamp() -- 日期+时间 select localtime() -- 日期+时间 select localtimestamp() -- 日期+时间 select curdate() -- 日期 select curtime() -- 时间 select current_time() -- 时间

sysdate() 日期时间函数跟 now() 类似,不同之处在于：now() 在执行开始时值就得到了, sysdate() 在函数执行时动态得到值
eg:select now(), sleep(3), now(); select sysdate(), sleep(3), sysdate();
格式转换 select UNIX_TIMESTAMP('2016-12-04 16:30:28') -- 把时间转换成时间戳 select FROM_UNIXTIME('1480581161',"%Y/%m/%d") -- 时间戳转换成时间 select time_to_sec('01:00:05'); -- 时间转换成秒 3605 select sec_to_time(3605); -- 秒转换成时间 '01:00:05' select to_days('2008-08-08'); -- 日期转换成天数 733627 select from_days(733627); -- 天数转换成日期 '2008-08-08' select date_format(now(),'%Y/%m/%d') -- 日期转化为字符串 select time_format('22:23:01', '%H.%i.%s'); -- 字符串转化为时间 select str_to_date('12.12.2016 14:09:30', '%m.%d.%Y %H:%i:%s'); -- 字符串转换为日期 2016-12-12 14:09:30

时间日期选取 set @dt = '2016-12-12 11:00:19.123456'; select date(@dt); -- 2016-12-12(日期类型) select time(@dt); -- 11:00:19.123456(日期类型) select year(@dt); -- 2016 select quarter(@dt); -- 4 (返回的一年日期,取值范围为1至4季度) select month(@dt); -- 12 select week(@dt); -- 50 select day(@dt); -- 12 select hour(@dt); -- 11 select minute(@dt); -- 0 select second(@dt); -- 19 select microsecond(@dt); -- 123456(返回微秒,在mysql中我没有找到显示当前微妙的函数,now()只精确到秒,也没有找到可以储存微妙的日期类型,,好玩的是却可以抽取微秒) select dayofweek(@dt); -- 2 (从周日算起) select dayofmonth(@dt); -- 12 select dayofyear(@dt); -- 347 select week(@dt); -- 50(有mode参数) select weekofyear(@dt); -- 50 select dayofweek(@dt); -- 2 select weekday(@dt); -- 0(返回日期的星期索引0=周一,1=周二,6=星期日) select yearweek(@dt); -- 201650(获取年份和周数)(有mode参数) select dayname(@dt); -- Monday select monthname(@dt); -- December select last_day(@dt); -- 2016-12-31(返回该月份的最后一天)

mode 参数相关 (用法 eg: select week( @dt ,3)😉 模式星期的第一天范围星期 1 是第一天 0 Sunday 0-53 一年中多一个星期天

1	Monday	0-53	一年多3天
2	Sunday	1-53	一年中多一个星期天
3	Monday	1-53	一年多3天
4	Sunday	0-53	一年多3天 5	6	7 Monday	Sunday	Monday 0-53	1-53	1-53 一年中多一个星期一	一年多3天	一年中多一个星期一

extract()选取函数 set @dt = '2016-12-12 11:21:19.123456'; select extract(year from @dt); -- 2016 select extract(quarter from @dt); -- 4 select extract(month from @dt); -- 12 select extract(week from @dt); -- 50 select extract(day from @dt); -- 12 select extract(hour from @dt); -- 11 select extract(minute from @dt); -- 21 select extract(second from @dt); -- 19 select extract(microsecond from @dt); -- 123456 select extract(year_month from @dt); -- 201712 select extract(day_hour from @dt); -- 1211 select extract(day_minute from @dt); -- 121121 select extract(day_second from @dt); -- 12112119 select extract(day_microsecond from @dt); -- 12112119123456 select extract(hour_minute from @dt); -- 1121 select extract(hour_second from @dt); -- 112119 select extract(hour_microsecond from @dt); -- 112119123456 select extract(minute_second from @dt); -- 2119 select extract(minute_microsecond from @dt); -- 2119123456 select extract(second_microsecond from @dt); -- 19123456

MySQL Extract() 函数除了没有date(),time() 的功能外,其他功能一应具全。并且还具有选取‘day_microsecond’ 等功能。注意这里不是只选取 day 和 microsecond,而是从日期的 day 部分一直选取到 microsecond 部分。
日期加减时间间隔 set @dt = '2016-12-12 11:21:19.123456'; select date_add(@dt, interval 1 day); -- 2016-12-13 11:21:19.123456 select date_add(@dt, interval 1 hour); -- 2016-12-12 12:21:19.123456 select date_add(@dt, interval 1 minute); -- 2016-12-12 11:22:19.123456 select date_add(@dt, interval 1 second); -- 2016-12-12 11:21:20.123456 select date_add(@dt, interval 1 microsecond); -- 2016-12-12 11:21:19.123457 select date_add(@dt, interval 1 week); -- 2016-12-19 11:21:19.123456 select date_add(@dt, interval 1 month); -- 2017-01-12 11:21:19.123456 select date_add(@dt, interval 1 quarter); -- 2017-03-12 11:21:19.123456 select date_add(@dt, interval 1 year); -- 2017-12-12 11:21:19.123456 select date_add(@dt, interval -1 day); -- 2016-12-11 11:21:19.123456 select date_add(@dt, interval '01:15:30' hour_second); -- 2016-12-12 12:36:49.123456 select date_add(@dt, interval '1 01:15:30' day_second); -- 2016-12-13 12:36:49.123456 select date_sub(@dt, interval '1 1:1:1' day_second); -- 2016-12-11 10:20:18.123456 -- 用法同 date_add select period_add(@dt,2); -- 202106 (日期加/减去N月,返回到月) select timestampadd(day, 1, '2016-12-12 12:00:00'); -- 2016-12-13 12:00:00 select timestampadd(day, 3, now()); -- 查询三天后的日期

日期差值计算 set @dt2 = '2010-10-10 10:10:10.123456'; set @dt1 = '2011-12-13 14:15:16.223456'; select datediff(@dt1,@dt2); -- 429(返回天数) select timediff(@dt1,@dt2); -- 838:59:59.000000(返回日期类型,返回time差值) select period_diff(@dt1,@dt2); -- 1 (返回月数) select timestampdiff(unit,datetime_expr1,datetime_expr2) eg: select timestampdiff(year,@dt1,@dt2); -- -1 select timestampdiff(day ,@dt1,@dt2); -- -429 select timestampdiff(hour,@dt1,@dt2); -- -10300

日期时间拼接 makdedate(year,dayofyear) eg select makedate(2001,32); -- '2001-02-01' maketime(hour,minute,second) eg select maketime(12,15,30); -- '12:15:30'

format 格式化标识 %W 星期名字(Sunday……Saturday) %D 有英语前缀的月份的日期(1st, 2nd, 3rd, 等等。） %Y 年,数字, 4 位 %y 年, 数字, 2 位 %a 缩写的星期名字(Sun……Sat) %d 月份中的天数, 数字(00……31) %e 月份中的天数, 数字(0……31) %m 月, 数字(01……12) %c 月, 数字(1……12) %b 缩写的月份名字(Jan……Dec) %j 一年中的天数(001……366) %H 小时(00……23) %k 小时(0……23) %h 小时(01……12) %I 小时(01……12) %l 小时(1……12) %i 分钟, 数字(00……59) %r 时间,12 小时(hh:mm:ss [AP]M) %T 时间,24 小时(hh:mm:ss) %S 秒(00……59) %s 秒(00……59) %p AM或PM %w 一个星期中的天数(0=Sunday ……6=Saturday ） %U 星期(0……52), 这里星期天是星期的第一天 %u 星期(0……52), 这里星期一是星期的第一天

时间段查询实例表tablename,添加时间是insert_time字段,该字段为int(5)类型的,现需要查询今天添加的文章总数并且按照时间从大到小排序,则查询语句如下： select * from tablename where date_format(from_UNIXTIME(insert_time),'%Y-%m-%d') = date_format(now(),'%Y-%m-%d'); 或者： select * from tablename where to_days(date_format(from_UNIXTIME(insert_time),'%Y-%m-%d')) = to_days(now()); 表的insert_time字段的存储类型是DATETIME类型或者TIMESTAMP类型,则查询语句也可按如下写法：查询今天的信息记录： select * from tablename where to_days(insert_time) = to_days(now()); 查询昨天的信息记录： select * from tablename where to_days(now()) - to_days(insert_time) <= 1; 查询近7天的信息记录： select * from tablename where date_sub(curdate(), INTERVAL 7 DAY) <= date(insert_time); 查询近30天的信息记录： select * from tablename where date_sub(curdate(), INTERVAL 30 DAY) <= date(insert_time); 查询本月的信息记录： select * from tablename where date_format(insert_time, '%Y%m') = date_format(curdate() , '%Y%m'); 查询上一月的信息记录： select * from tablename where period_diff(date_format(now() , '%Y%m') , date_format(insert_time, '%Y%m')) =1;
转载请注明出处！

数据库

2019-05-05 09:33:00

物化视图的CONSIDER FRESH语句

「深度学习福利」大神带你进阶工程师,立即查看>>>
物化视图的修改语句
ALTER MATERIALIZED VIEW
包含了
CONSIDER FRESH
语句。通过这个语句可以使得数据库认为物化视图已经是刷新后的状态。同时可以使得这个物化视图对于查询重新生效。
CONSIDER FRESH语句的另一个主要功能就是使得物化视图可以继续为查询重写所使用。
查询重新包括三个级别的参数：ENFORCED、TRUSTED和STALE_TOLERATED。对于一个无法刷新到FRESH状态的物化视图,只有STALE_TOLERATED级别的查询重新可以考虑读取这个物化视图,而使用了CONSIDER FRESH语句后,在TRUSTED级别 Oracle 在查询重写的时候也可以使用这个物化视图：
SQL > DROP TABLE T PURGE;
表已删除。
SQL> DROP MATERIALIZED VIEW MV_T;
实体化视图已删除。
SQL> CREATE TABLE T
2 (ID NUMBER,
3 NAME VARCHAR2(30),
4 TYPE VARCHAR2(18),
5 CREATE_DATE DATE);
表已创建。
SQL> INSERT INTO T
2 SELECT ROWNUM,
3 OBJECT_NAME,
4 OBJECT_TYPE,
5 CREATED
6 FROM ALL_OBJECTS;
已创建55680行。
SQL> COMMIT;
提交完成。
SQL> CREATE MATERIALIZED VIEW LOG ON T
2 WITH ROWID, SEQUENCE (TYPE)
3 INCLUDING NEW VALUES;
实体化视图日志已创建。
SQL> CREATE MATERIALIZED VIEW MV_T
2 REFRESH FAST
3 ENABLE QUERY REWRITE
4 AS SELECT TYPE, COUNT(*)
5 FROM T
6 GROUP BY TYPE;
实体化视图已创建。
首先建立了测试的物化视图,然后检查一下查询重写的配置：
SQL> SHOW PARAMETER QUERY_REWRITE
NAME TYPE VALUE

query_rewrite_enabled string TRUE
query_rewrite_integrity string enforced
SQL> @?/ rdbms /admin/utlxrw
表已创建。
SQL> EXEC DBMS_MVIEW.EXPLAIN_REWRITE('SELECT TYPE, COUNT(*) FROM T GROUP BY TYPE')
PL/SQL 过程已成功完成。
SQL> SELECT MESSAGE
2 FROM REWRITE_TABLE;
MESSAGE

QSM-01151: 已重写查询
QSM-01209: 已通过实体化视图 MV_T, 采用文本匹配算法进行了查询重写
SQL> TRUNCATE TABLE REWRITE_TABLE;
表被截断。
SQL> INSERT INTO T
2 VALUES (1, ' TEST ', 'T', SYSDATE);
已创建 1 行。
SQL> COMMIT;
提交完成。
SQL> EXEC DBMS_MVIEW.EXPLAIN_REWRITE('SELECT TYPE, COUNT(*) FROM T GROUP BY TYPE')
PL/SQL 过程已成功完成。
SQL> SELECT MESSAGE
2 FROM REWRITE_TABLE;
MESSAGE

QSM-01150: 未重写查询
QSM-01029: 实体化视图 MV_T 在 ENFORCED 完整性模式中已过时
SQL> ALTER SESSION SET QUERY_REWRITE_INTEGRITY = STALE_TOLERATED;
会话已更改。
SQL> TRUNCATE TABLE REWRITE_TABLE;
表被截断。
SQL> EXEC DBMS_MVIEW.EXPLAIN_REWRITE('SELECT TYPE, COUNT(*) FROM T GROUP BY TYPE')
PL/SQL 过程已成功完成。
SQL> SELECT MESSAGE
2 FROM REWRITE_TABLE;
MESSAGE

QSM-01151: 已重写查询
QSM-01209: 已通过实体化视图 MV_T, 采用文本匹配算法进行了查询重写
SQL> TRUNCATE TABLE REWRITE_TABLE;
表被截断。
SQL> ALTER SESSION SET QUERY_REWRITE_INTEGRITY = TRUSTED;
会话已更改。
SQL> EXEC DBMS_MVIEW.EXPLAIN_REWRITE('SELECT TYPE, COUNT(*) FROM T GROUP BY TYPE')
PL/SQL 过程已成功完成。
SQL> SELECT MESSAGE
2 FROM REWRITE_TABLE;
MESSAGE

QSM-01150: 未重写查询
QSM-01031: 实体化视图 MV_T 在 TRUSTED 完整性模式中已过时
可以看到,和前面分析的一样,一旦物化视图的数据和基表中的最新的数据存在差异,这个物化视图在TRUSTED模式下无法被查询重写所使用。
下面使用CONSIDER FRESH语句：
SQL> TRUNCATE TABLE REWRITE_TABLE;
表被截断。
SQL> ALTER MATERIALIZED VIEW MV_T
2 CONSIDER FRESH;
实体化视图已更改。
SQL> EXEC DBMS_MVIEW.EXPLAIN_REWRITE('SELECT TYPE, COUNT(*) FROM T GROUP BY TYPE')
PL/SQL 过程已成功完成。
SQL > SELECT MESSAGE
2 FROM REWRITE_TABLE;
MESSAGE

QSM-01151: 已重写查询
QSM-01209: 已通过实体化视图 MV_T, 采用文本匹配算法进行了查询重写
通过使用 CONSIDER FRESH ,数据库重新认为物化视图已经和基表的数据保持一致,因此TRUSTED模式下,物化视图重新可以被查询重写机制所使用。

数据库

2019-05-04 17:30:00

Mysql 数据库索引失效

「深度学习福利」大神带你进阶工程师,立即查看>>>
1.如果条件中有or,即使其中有条件带索引也不会使用(这也是为什么尽量少用or的原因)
注意：要想使用or,又想让索引生效,只能将or条件中的每个列都加上索引
2.对于多列索引,不是使用的第一部分,则不会使用索引
3.like查询是以%开头
4.如果列类型是字符串,那一定要在条件中将数据使用引号引用起来,否则不使用索引

数据库

2019-05-04 17:01:00

win10下安装MySQL 8.0免安装版本步骤

「深度学习福利」大神带你进阶工程师,立即查看>>>
安装过程：
1.去官网下载mysql 8.0 解压版mysql
2.直接解压,解压路径为（F:\develop\mysql-8.0.16-winx64,可以自己决定,建议不要选择C盘）,配置path路径（F:\develop\mysql-8.0.16-winx64\bin追加到path下）
3.cmd（超级管理员下）进入到mysql的bin目录下。
4. mysqld --initialize --console 生成data目录,console会显示root用户密码,记住这个初始密码,后面需要用到
5. mysqld --install ,检查服务中是否出现了mysql,出现了表示安装完成,出现安装失败的,可能是因为不是超级管理员打开的cmd。
6. net start mysql ,启动成功则成功,启动失败的话,看看my.ini文件,删除skip-grant-tables（8.0不允许直接跳过密码）
7. mysql -uroot -p ,输入初始密码,登录
8.修改初始密码 ALTER USER 'root'@'localhost' IDENTIFIED BY '新密码' PASSWORD EXPIRE NEVER;
退出重新登录。
附：
1.登陆的时候,容易出现
Access denied for user 'root'@'localhost' (using password: NO)
Access denied for user 'root'@'localhost' (using password: YES)
解决办法：
1.多尝试输入几次密码,密码错误的概率比较大,因为密码是初始化随机生成的,建议先在文本文件中打出来,直接复制到cmd中。
2.参考其他大部分解决方案都是在my.ini文件的[mysqld]下添加skip-grant-tables,添加这个将导致net start mysql无法启动mysql服务,使用命令行的方式 # 这里路径改为自己路径 mysqld --defaults-file="F:\develop\mysql-8.0.16-winx64\my.ini" --console --skip-grant-tables
使用这个命令的时候,步骤4初始化生成的data文件夹不要删除,然后重新输入 mysql -uroot -p ,输入密码登录（初始密码）进行登录,本人使用这个方式成功登录,但是也怀疑是密码或者命令输入错误, mysql -uroot -p 多次输入成了mysql -u root -p
2.my.ini文件 [mysqld] # 设置3306端口 port=3306 # 设置mysql的安装目录 basedir=F:\develop\mysql-8.0.16-winx64 # 设置mysql数据库的数据的存放目录 datadir=F:\develop\mysql-8.0.16-winx64\data # 允许最大连接数 max_connections=200 # 允许连接失败的次数。这是为了防止有人从该主机试图攻击数据库系统 max_connect_errors=10 # 服务端使用的字符集默认为UTF8 character-set-server=utf8 # 创建新表时将使用的默认存储引擎 default-storage-engine=INNODB # 默认使用“mysql_native_password”插件认证 default_authentication_plugin=mysql_native_password [mysql] # 设置mysql客户端默认字符集 default-character-set=utf8 [client] # 设置mysql客户端连接服务端时默认使用的端口 port=3306 default-character-set=utf8

数据库

2019-05-04 15:26:00

redis redis击穿、雪崩的预防解决方案

「深度学习福利」大神带你进阶工程师,立即查看>>>
redis的缓存击穿？
缓存穿透是指查询一个根本不存在的数据,缓存层和存储层都不会命中,但是出于容错的考虑,如果从存储层查不到数据则不写入缓存层,如图 11-3 所示整个过程分为如下 3 步：缓存层不命中存储层不命中,所以不将空结果写回缓存返回空结果
缓存穿透将导致不存在的数据每次请求都要到存储层去查询,失去了缓存保护后端存储的意义。
缓存穿透模型
缓存穿透问题可能会使后端存储负载加大,由于很多后端存储不具备高并发性,甚至可能造成后端存储宕掉。通常可以在程序中分别统计总调用数、缓存层命中数、存储层命中数,如果发现大量存储层空命中,可能就是出现了缓存穿透问题。
造成缓存穿透的基本有两个。第一,业务自身代码或者数据出现问题,第二,一些恶意攻击、爬虫等造成大量空命中,下面我们来看一下如何解决缓存穿透问题。
缓存穿透的解决方法
1）缓存空对象
如下图所示,当第 2 步存储层不命中后,仍然将空对象保留到缓存层中,之后再访问这个数据将会从缓存中获取,保护了后端数据源。
缓存空值应对穿透问题
缓存空对象会有两个问题：
第一,空值做了缓存,意味着缓存层中存了更多的键,需要更多的内存空间 ( 如果是攻击,问题更严重 ),比较有效的方法是针对这类数据设置一个较短的过期时间,让其自动剔除。
第二,缓存层和存储层的数据会有一段时间窗口的不一致,可能会对业务有一定影响。例如过期时间设置为 5 分钟,如果此时存储层添加了这个数据,那此段时间就会出现缓存层和存储层数据的不一致,此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。
下面给出了缓存空对象的实现伪代码：
2）布隆过滤器拦截
如下图所示,在访问缓存层和存储层之前,将存在的 key 用布隆过滤器提前保存起来,做第一层拦截。例如：一个个性化推荐系统有 4 亿个用户 ID,每个小时算法工程师会根据每个用户之前历史行为做出来的个性化放到存储层中,但是最新的用户由于没有历史行为,就会发生缓存穿透的行为,为此可以将所有有个性化推荐数据的用户做成布隆过滤器。如果布隆过滤器认为该用户 ID 不存在,那么就不会访问存储层,在一定程度保护了存储层。
开发提示：
有关布隆过滤器的相关知识,可以参考： https://en.wikipedia.org/wiki/Bloom_filter
可以利用 Redis 的 Bitmaps 实现布隆过滤器,GitHub 上已经开源了类似的方案,读者可以进行参考：
https://github.com/erikdubbelboer/Redis-Lua-scaling-bloom-filter
使用布隆过滤器应对穿透问题
这种方法适用于数据命中不高,数据相对固定实时性低（通常是数据集较大）的应用场景 ,代码维护较为复杂,但是缓存空间占用少。
两种方案对比
前面介绍了缓存穿透问题的两种解决方法 ( 实际上这个问题是一个开放问题,有很多解决方法 ),下面通过下表从适用场景和维护成本两个方面对两种方案进行分析。
缓存空对象和布隆过滤器方案对比
###redis的缓存雪崩？
从下图可以很清晰出什么是缓存雪崩：由于缓存层承载着大量请求,有效的保护了存储层,但是如果缓存层由于某些原因整体不能提供服务,于是所有的请求都会达到存储层,存储层的调用量会暴增,造成存储层也会挂掉的情况。缓存雪崩的英文原意是 stampeding herd（奔逃的野牛）,指的是缓存层宕掉后,流量会像奔逃的野牛一样,打向后端存储。
缓存层不可用引起的雪崩
预防和解决缓存雪崩问题,可以从以下三个方面进行着手。
1）保证缓存层服务高可用性。
和飞机都有多个引擎一样,如果缓存层设计成高可用的,即使个别节点、个别机器、甚至是机房宕掉,依然可以提供服务,例如前面介绍过的 Redis Sentinel 和 Redis Cluster 都实现了高可用。
2）依赖隔离组件为后端限流并降级。
无论是缓存层还是存储层都会有出错的概率,可以将它们视同为资源。作为并发量较大的系统,假如有一个资源不可用,可能会造成线程全部 hang 在这个资源上,造成整个系统不可用。降级在高并发系统中是非常正常的：比如推荐服务中,如果个性化推荐服务不可用,可以降级补充热点数据,不至于造成前端页面是开天窗。
在实际项目中,我们需要对重要的资源 ( 例如 Redis、 MySQL、 Hbase、外部接口 ) 都进行隔离 ,让每种资源都单独运行在自己的线程池中,即使个别资源出现了问题,对其他服务没有影响。但是线程池如何管理,比如如何关闭资源池,开启资源池,资源池阀值管理,这些做起来还是相当复杂的,这里推荐一个 Java 依赖隔离工具 Hystrix( https://github.com/Netflix/Hystrix ),如下图所示。

数据库

2019-05-02 14:33:00

redis RedisTemplate实现乐观锁赋值

「深度学习福利」大神带你进阶工程师,立即查看>>>
我们在高并发使用redis时,我们不止需要采用分布式事务的模式,还需要采用乐观锁保证数据安全。
redis乐观锁的实现一定要伴随着redis事务。
话不多说直接上代码 redisTemplate.watch("key"); // 1 redisTemplate.multi(); redisTemplate.boundValueOps("key").set(""+id); List

咨询电话(周一至周五9：00-18：00)