专注上位机开发、机器视觉、机器学习、嵌入式软硬件开发

比如我现在要进行LRU，那么首先拿到当前的全局时钟，然后再找到内部时钟与全局时钟距离时间最久的（差最大）进行淘汰，这里值得注意的是全局时钟只有24位，按秒为单位来表示才能存储194天，所以可能会出现key的时钟大于全局时钟的情况，如果这种情况出现那么就两个相加而不是相减来求最久的key。当字典的某个元素被访问时，它在链表中的位置会被移动到表头。它的全称是Least Frequently Used，它的核心思想是根据key的最近被访问的频率进行淘汰，很少被访问的优先被淘汰，被访问的多的则被留下来。

多线程模型虽然在某些方面表现优异，但是它却引入了程序执行顺序的不确定性，带来了并发读写的一系列问题，增加了系统复杂度、同时可能存在线程切换、甚至加锁解锁、死锁造成的性能损耗。Redis 为各种文件事件需求编写了多个处理器，若客户端连接Redis，对连接服务器的各个客户端进行应答，就需要将socket映射到连接应答处理器写数据到Redis，接收客户端传来的命令请求，就需要映射到命令请求处理器从Redis读数据，向客户端返回命令的执行结果，就需要映射到命令回复处理器当主服务器和从服务器进行复制操作时，

bigkey是指key对应的value所占的内存空间比较大，例如一个字符串类型的value可以最大存到512MB，一个列表类型的value最多可以存储23-1个元素。如果按照数据结构来细分的话，一般分为字符串类型bigkey和非字符串类型bigkey。字符串类型：体现在单个value值很大，一般认为超过10KB就是bigkey，但这个值和具体的OPS相关。非字符串类型：哈希、列表、集合、有序集合,体现在元素个数过多。bigkey无论是空间复杂度和时间复杂度都不太友好，下面我们将介绍它的危害。

简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；是指查询一个根本不存在的数据，缓存层和存储层都不会命中，于是这个请求就可以随意访问数据库，这个就是缓存穿透，缓存穿透将导致不存在的数据每次请求都要到存储层去查询，失去了缓存保护后端存储的意义。更新的时候，先更新数据库，然后再删除缓存。

当Sentinel主观下线的节点是主节点时，该Sentinel节点会通过sentinel is-master-down-by-addr命令向其他Sentinel节点询问对主节点的判断，当超过<quorum>个数,Sentinel节点认为主节点确实有问题，这时该Sentinel节点会做出客观下线的决定，这样客观下线的含义是比较明显了，也就是大部分Sentinel节点都对主节点的下线做了同意的判定，那么这个判定就是客观的。假如Sentinel节点对于主节点已经做了客观下线，那么是不是就可以立即进行故障转移了？

在统计信息中可以看到从节点slave信息，分别记录了从节点的ip和 port，从节点的状态，offset表示当前从节点的复制偏移量，master_repl_offset表示当前主节点的复制偏移量，两者的差值就是当前从节点复制延迟量。当从节点(slave)正在复制主节点（master)时，如果出现网络闪断或者命令丢失等异常情况时，从节点会向主节点要求补发丢失的命令数据，如果主节点的复制积压缓冲区内存在这部分数据则直接发送给从节点，这样就可以保持主从节点复制的一致性。默认情况下，Redis都是主节点。

配置纪元是一个只增不减的整数，每个主节点自身维护一个配置纪元(clusterNode .configEpoch)标示当前主节点的版本，所有主节点的配置纪元都不相等，从节点会复制主节点的配置纪元。每个从节点都要检查最后与主节点断线时间，判断是否有资格替换故障的主节点。另外，当集群 Master 节点个数小于 3 个的时候，或者集群可用节点个数为偶数的时候，基于 fail 的这种选举机制的自动主从切换过程可能会不能正常工作，一个是标记 fail 的过程，一个是选举新的 master 的过程，都有可能异常。

由于键对应槽是5798，不属于6900节点，则回复 MOVED (slot}{ip} {port]格式重定向信息，重定向信息包含了键所对应的槽以及负责该槽的节点地址,根据这些信息客户端就可以向正确的节点发起请求。在集群模式下，Redis接收任何键相关命令时首先计算键对应的槽,再根据槽找出所对应的节点，如果节点是自身，则处理键命令;首先来看我们之前搭建的集群槽和数据与节点的对应关系。三个主节点分别维护自己负责的槽和对应的数据，如果希望加入1个节点实现集群扩容时，需要通过相关命令把一部分槽和数据迁移给新节点。

Redis集群中，在握手成功后，连个节点之间会定期发送ping/pong消息，交换数据信息，集群中节点数量越多，消息体内容越大，比如说10个节点的状态信息约1kb，同时redis集群内节点，每秒都在发ping消息。如下图所示，三个节点真实节点：Node1、Node2和Node3，每个真实节点虚拟出三个虚拟节点：X#V1、X#V2和X#V3，这样每个真实节点所负责的hash空间不再是连续的一段，而是分散在环上的各处，这样就可以将局部的压力均衡到不同的节点，虚拟节点越多，分散性越好，理论上负载就越倾向均匀。

Redlock 只有建立在「时钟正确」的前提下，才能正常工作，如果你可以保证这个前提，那么可以拿来使用。但是时钟偏移在现实中是存在的：第一，从硬件角度来说，时钟发生偏移是时有发生，无法避免。例如，CPU 温度、机器负载、芯片材料都是有可能导致时钟发生偏移的。第二，人为错误也是很难完全避免的。所以，Redlock尽量不用它，而且它的性能不如单机版 Redis，部署成本也高，优先考虑使用主从+ 哨兵的模式实现分布式锁（只会有很小的记录发生主从切换时的锁丢失问题）。

该状态开启后，如果执行bgrewriteaof命令，则会把当前内存中已有的数据弄成二进程存放在aof文件中，这个过程模拟了rdb生成的过程，然后Redis后面有其他命令，在触发下次重写之前，依然采用AOF追加的方式。加载损坏的AOF 文件时会拒绝启动，对于错误格式的AOF文件，先进行备份，然后采用redis-check-aof --fix命令进行修复，对比数据的差异，找出丢失的数据，有些可以人工修改补全。随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入AOF重写机制压缩文件体积。

先有一个桶，桶的容量是固定的。以任意速率向桶流入水滴，如果桶满了则溢出(被丢弃)。桶底下有个洞，按照固定的速率从桶中流出水滴。

事务是Redis实现在服务器端的行为，用户执行MULTI命令时，服务器会将对应这个用户的客户端对象设置为一个特殊的状态，在这个状态下后续用户执行的查询命令不会被真的执行，而是被服务器缓存起来，直到用户执行EXEC命令为止，服务器会将这个用户对应的客户端对象中缓存的命令按照提交的顺序依次执行。所谓慢查询日志就是系统在命令执行前后计算每条命令的执行时间，当超过预设阀值,就将这条命令的相关信息（例如:发生时间，耗时，命令的详细信息）记录下来，Redis也提供了类似的功能。另外discard命令是回滚。

足够简单，消费消息延迟几乎为零，但是需要处理空闲连接的问题。如果线程一直阻塞在那里，Redis客户端的连接就成了闲置连接，闲置过久，服务器一般会主动断开连接，减少闲置资源占用，这个时候blpop和brpop或抛出异常，所以在编写客户端消费者的时候要小心，如果捕获到异常，还有重试。其他缺点包括：做消费者确认ACK麻烦，不能保证消费者消费消息后是否成功处理的问题（宕机或处理异常等），通常需要维护一个Pending列表，保证消息处理确认；不能做广播模式，如pub/sub，消息发布/订阅模型；

1970 年布隆提出了一种布隆过滤器的算法，用来判断一个元素是否在一个集合中。这种算法由一个二进制数组和一个 Hash 算法组成。本质上布隆过滤器是一种数据结构，比较巧妙的概率型数据结构（probabilistic data structure），特点是高效地插入和查询，可以用来告诉你 “某样东西一定不存在或者可能存在”。相比于传统的 List、Set、Map 等数据结构，它更高效、占用空间更少，但是缺点是其返回的结果是概率性的，而不是确切的。

有序集合相对于哈希、列表、集合来说会有一点点陌生,但既然叫有序集合,那么它和集合必然有着联系,它保留了集合不能有重复成员的特性,但不同的是,有序集合中的元素可以排序。例如一个电子商务的网站会对不同标签的用户做不同类型的推荐，比如对数码产品比较感兴趣的人，在各个页面或者通过邮件的形式给他们推荐最新的数码产品，通常会为网站带来更多的利益。集合( set）类型也是用来保存多个的字符串元素,但和列表类型不一样的是，集合中不允许有重复元素,并且集合中的元素是无序的,不能通过索引下标获取元素。

Redis可以支撑每秒数万的读写操作，但是这指的是Redis服务端的处理能力，对于客户端来说，一次命令除了命令时间还是有网络时间，假设网络时间为1毫秒，命令时间为0.1毫秒(按照每秒处理1万条命令算)，那么执行1000次 get命令需要1.1秒(1000。字符串这些命令中，除了del 、mset、 mget支持多个键的批量操作，时间复杂度和键的个数相关，为O(n)，getrange和字符串长度相关，也是O(n)，其余的命令基本上都是O(1)的时间复杂度，在速度上还是非常快的。我们以brpop为例说明。

我们要首先理解一点，我们把Redis称为KV数据库，键值对数据库，那就可以把Redis内部的存储视为存在着一个巨大的Map，对Map的操作无非就是get和put，然后通过key操作这个key所对应的value，而这个value的类型可以多种多样，也就是Redis为我们提供的那些数据结构，比如字符串（String）、哈希(Hash)等等。这些年李老师的经历，我发现，很多技术人都有一个误区，那就是，只关注零散的技术点，没有建立起一套完整的知识框架，缺乏系统观，但是系统观其实是至关重要的。

和SQL一样，Neo4j CQL提供了一些在RETURN子句中使用的聚合函数。与SQL一样，Neo4J CQL提供了一组String函数，用于在CQL查询中获取所需的结果。Neo4j CQL提供了一组关系函数，以在获取开始节点，结束节点等细节时知道关系的细节。我们可以使用MATCH命令中的RETURN +聚合函数来处理一组节点并返回一些聚合值。@StartNode：开始节点（可以理解为父节点）@EndNode：结束节点（可以理解为子节点）@NodeEntity：标明是一个节点实体。然后创建对应的实体对象。

当我们创建一个具有现有节点标签名称但未指定其属性值的节点时，它将创建一个具有NULL属性值的新节点。结果列类型，并从两个结果集的名字必须匹配，这意味着列名称应该是相同的，列的数据类型应该是相同的。结果列类型和来自两组结果的名称必须匹配，这意味着列名称应该相同，列的数据类型应该相同。如果我们要修整CQL查询结果集顶部的结果，那么我们应该使用CQL SKIP子句。Neo4j CQL将空值视为对节点或关系的属性的缺失值或未定义值。有时，根据我们的客户端要求，我们需要向现有节点或关系添加新属性。

Neo4j的Cypher语言是为处理图形数据而构建的，CQL代表Cypher查询语言。像Oracle数据库具有查询语言SQL，Neo4j具有CQL作为查询语言。它是Neo4j图形数据库的查询语言。它是一种声明性模式匹配语言它遵循SQL语法。它的语法是非常简单且人性化、可读的格式。

随着社交、电商、金融、零售、物联网等行业的快速发展，现实社会织起了了一张庞大而复杂的关系网，传统数据库很难处理关系运算。大数据行业需要处理的数据之间的关系随数据量呈几何级数增长，急需一种支持海量复杂数据关系运算的数据库，图数据库应运而生。社交领域：Facebook, Twitter，Linkedin用它来管理社交关系，实现好友推荐零售领域：eBay，沃尔玛使用它实现商品实时推荐，给买家更好的购物体验金融领域：摩根大通，花旗和瑞银等银行在用图数据库做风控处理。

也可以加在类上（不要添加在类上，这样很多细粒度配置就无法实现，比如@Transactional），可以在执行当前方法前，根据注解查看方法的返回内容是否已经被缓存，如果已经缓存，不需要执行业务代码，直接返回数据。前面配置好关于CacheManager之后，就可以在Service层添加Cache注解，实现缓存使用，缓存更新，缓存清除。可以设置sync属性为true，代表当执行Service方法时，发现缓存没数据，那么就需要去竞争锁资源去执行业务代码，后续线程等待前置线程执行完，再去直接查询缓存即可。

在查询数据的时候，数据大多来自数据库，咱们会基于SQL语句的方式与数据库交互，数据库一般会基于本地磁盘IO的形式将数据读取到内存，返回给Java服务端，Java服务端再将数据响应给客户端，做数据展示。但是MySQL这种关系型数据库在查询数据时，相对比较慢，因为有磁盘IO，有时没命中索引还需要全盘扫描。在针对一些热点数据时，如果完全采用MySQL，会存在俩问题。第一个MySQL相对很脆弱，肯能会崩，第二个MySQL查询效率慢。会采用缓存。

根据节点定义一个Zone,比如国际区号：1开头的读写美国的服务器，86开头的读写中国的服务器，方便完成国际化的全球项目的部署。

readConcern 决定这个节点上的数据哪些是可读的，类似于关系数据库的隔离级别。可选值包括：• available：读取所有可用的数据;• local：读取所有可用且属于当前分片的数据;• majority：读取在大多数节点上提交完成的数据;• linearizable：可线性化读取文档;• snapshot：读取最近快照中的数据;

writeConcern 决定一个写操作落到多少个节点上才算成功。writeConcern 的取值包括：• 0：发起写操作，不关心是否成功；• 1~n(n为集群最大数据节点数）：写操作需要被复制到指定节点数才算成功；• majority：写操作需要被复制到大多数节点上才算成功。发起写操作的程序将阻塞到写操作到达指定的节点数为止默认行为w: “1”默认的writeConcern，数据写入到Primary就向客户端发送确认大多数节点确认模式w: “all”全部节点确认模式j:true。

这种扫描全集合的查询效率是非常低的，特别在处理大量的数据时，查询可以要花费几十秒甚至几分钟，这对网站的性能是非常致命的。注意B-树中的B不是代表二叉(binary)，而是代表平衡(balance)，因为B-树是从最早的平衡二叉树演化而来，但是B-树不是一个二叉树。skip(), limit(), sort()三个放在一起执行的时候，执行的顺序是先 sort(), 然后是 skip()，最后是显示的 limit()，和命令编写顺序无关。平衡二叉树的查找性能是比较高的，但是维护一棵平衡二叉树的代价是非常大的。

NoSQL（Not Only SQL）是一类非关系型数据库的统称，其核心特征在于突破传统关系型数据库的结构化存储模式，通过灵活的数据模型和分布式架构应对现代应用中的大规模数据处理需求。1. 核心特征数据模型灵活：无需预定义固定表结构，支持半结构化或非结构化数据（如JSON、键值对、图结构）。横向扩展性：通过分布式架构轻松扩展节点，适应数据量激增与高并发场景。性能优化：牺牲部分ACID特性（如强一致性）以换取高吞吐量与低延迟。场景导向：针对特定用例设计，如文档存储、实时分析、社交网络关系等。

FastDFS是余庆国人开发的一个开源的轻量级分布式文件系统，它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。特别适合以文件为载体的在线服务，如相册网站、视频网站等等。FastDFS为互联网量身定制，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标，使用FastDFS很容易搭建一套高性能的文件服务器集群提供文件上传、下载等服务。FastDFS是一个轻量级的开源分布式文件系统。

Mycat2支持常用的(自动)HASH型分片算法也兼容1.6的内置的(cobar)分片算法.HASH型分片算法默认要求集群名字以c为前缀,数字为后缀, c0就是分片表第一个节点, c1就是第二个节点.该命名规则允许用户手动改变。分片规则与适用性详细请参考?1.MOD_HASH如果分片值是字符串则先对字符串进行hash转换为数值类型1.分库键和分表键是同1个键分表下标=分片值%(分库数量*分表数量)分库下标=分表下标/分表数量2.分库键和分表键是不同键分表下标= 分片值%分表数量。

虽然一主一从或一主多从集群解决了并发读的问题，但由于主节点只有一台，如果主节点宕机了，则数据库的写操作便无法完成，从而无法做到高可用。因此，接下来我们来完成Mysql双主双从的集群搭建，双主双从的原理很简单，相当于有两个一主一从，然后两个主节点再互为主从，互相复制数据，然后借助MyCat的机制，先把一台主作为写库，另一台主和两台从作为读库，当作为写库的主宕机后，另一台主则作为写库提供服务，从而实现高可用。角色端口机器名master13310slave13311master23312。

当我们的数据库实现读写分离的时候，在应⽤中需要对数据源进⾏切换， MyCat能够帮我们更好的实现数据源的动态切换，也就是应⽤程序只需要连接MyCat中间件，⾃动帮我们读取读写的数据库。为了提供数据库的并发能⼒和负载能⼒,⼀般通过读写分离来实现。在主节点(主库)创建mycat数据库，供mycat内部使用，Mycat 在启动时，会自动在原型库下创建其运行时所需的数据表。**注意：**这里不要删除 prototype.cluster.json，否则启动 Mycat 时会报错。创建一个读写分离的测试库。

实现读写分离是基于MySQL的主从复制架构的，通过一主多从的配置方式，可以将查询请求均匀的分散到多个数据副本，能够进一步的提升系统的处理能力。数据库复制被用来把事务性查询导致的数据变更同步到从库，同时主库也可以select查询。默认情况下MySQL的binlog日志是自动开启的，可以通过如下配置定义一些可选配置。执行完此步骤后,不要再操作主服务器，防止主服务器状态值变化,可以选择锁住主服务器。在主库创建数据库、表，插入数据，测试从库是否同步数据。我们可以选择配置多台从服务器，配置方式都是一样的。

Mycat2作为一个数据库中间件，它所有的功能其实都是通过一些列配置文件定制一系列业务规则，通过与MySQL协作，提供具体的业务功能。所有Mycat2的所有功能都体现在他的配置文件中。Mycat2不提供安装包,只提供核心JAR包,JAR包可以独立运行,安装包是使用Java Service Wrapper做壳的,如果需要安装包，需要自己制作。JAR可以作为Java库引入自己业务项目中使用,Mycat2中的各个组件的设计都是可以独立使用的。mycat连接真正数据库的信息目录是在。1）配置集群信息，所在目录。

官网：Mycat 是基于 java 语言编写的数据库中间件，是一个实现了 MySQL 协议的服务器，前端用户可以把它看作是一个数据库代理，用 MySQL 客户端工具和命令行访问，而其后端可以用 MySQL 原生协议与多个 MySQL 服务器通信，也可以用 JDBC 协议与大多数主流数据库服务器通信，其核心功能是分库分表和读写分离，即将一个大表水平分割为 N 个小表，存储在后端 MySQL 服务器里或者其他数据库里。