qq_61839608的博客

原创 雪花算法（仅供自己参考）

仅供自己参考

原创 手写Mybatis框架源码（简写）

总得来说，通过Proxy生成代理对象，通过代理对象调用相应的方法，相应的方法从configurations拿到相应的方法需要执行的sql语句。通过这个sql语句去执行JDBC基础的语句，也就是通过Connections去执行语句。8、DatasourceXmlBuilder：我在这里写死了，当然可以通过解析或者配置yml文件去读取。ExectuorImpl： 这段代码就不加注释了，自己理解了就好理解整个过程。springboot版本：2.6.5。

原创 ES集群搭建（仅供自己参考）

2、查询：如果不是通过id具体的查询，那么在查询的时候不会走计算hash值，然后到相应的分片上去查。再把相应的数据传到coordinating node（协调节点），协调节点将所有的数据进行一个整合，把整合数据返回用户。如果新增一个分片，那么shard值没变，那么始终得到不到新增分片的id。单节点问题：单机的elasticsearch做数据存储，面临的两个问题：海量的数据存储问题、单节点故障。当节点恢复的时候，它会将一个分片和一个备份重新分配给node1节点，使得每一个节点都能均衡的有分片。

原创 es数据同步（仅供自己参考）

MySQL在进行增删改的时候会将操作记录到binlog上，然后在使用canal（通道）中间件，通知es发生改变，这样就会使得es数据得到更新。当服务对MySQL进行增删改的时候，这个时候使用fegin远程调用，将所更改的数据发送到es的服务上，使得es数据得到及时的更新。当MySQL进行增删改查的时候，数据库的数据有所改变，这个时候需要修改es中的索引库的值，这个时候就涉及到了数据同步的问题。使用消息中间件rabbitMQ，服务进行增删改的时候将信息放到MQ，es的服务去MQ中拿到信息，去更新自己的数据。

原创 es自动补全（仅供自己参考）

elasticssearch提供了CompletionSuggester查询来实现自动补全功能。这个查询会匹配以用户输入内容开头的词条并返回。完成一个hotel酒店的es库创建：（创建了两个自定义的分词器）+ 查询类型必须是：completion。+ 字段内容是多个补全词条形成的数组。

原创 es拼音分词器（仅供自己参考）

自定义分词器的配置：（只能是相应的索引库使用，创建了test索引库，那么自定义的只能在这个索引库中使用。默认的拼音分词器会将每个汉字单独分为拼音，而我们希望的是每个词条形成一组拼音，需要对拼音分词器做个性化定制，形成自定义分词器。为了避免搜索的时候使用拼音搜到同音词，所以在搜索的时候使用ik分词器"search_analyzer": "ik_smart"3、tokenizer filter：将tokenizer输出的词条做进一步处理。1、是直接将每个字的拼音返回和一段话的拼音首字母返回，不能很好的分词。

原创 ES聚合（仅供自己参考）

2、度量（Metric）聚合：用以计算一些值，AVG,MAX,MIN,SUM,STATS(都做前面的几个)+ Date Histogram：按照日期阶梯分组，例如一周为一组，或者一月为一组。3、管道聚合（Pipeline）：其他聚合的结果为基础做聚合（比如度量和桶的结果做基础）4、参与聚合的字段不能是可分词的（Text类型）：keyword，Date，数值，布尔。1、聚合：可以实现对文档数据的统计、分析、运算。1、桶（Bucket）聚合：用来对文档做分组。聚合嵌套和Metric聚合。

原创 ES（2）（仅供自己参考）

比如查询9990-10000的数据，es会首先查询出0-10000的数据，在对0-10000的数据截取，截取出9990-10000的文档数据。你查询9990-10000的数据就是从每个集群中查询0-10000的数据，然后将所有文档数据排序，然后将数据截取。如果是在分布式集群下面（es集群是为了尽可能多的存储数据，所以每个集群的数据不同）造成的问题，每个集群查需要时间，数据之间的排序需要时间，耗费的时间很大很大。复合查询：简单查询的组合，实现复杂的查询。数字排序sort：（双条件排序）

原创 es（1）（仅供自己参考）

正排索引适合需要快速访问完整记录的情况，优于范围查询。倒排索引则适合文本检索，能够高效支持关键词搜索自己的理解正排索引：通过检索全部数据（例如mysql的每行，有很多行数据）将每一行的数据与关键字比对，如果匹配则添加到返回序列当中。倒排索引：两个字段：词条和文档id（）词条：包含一个文档中的一些关键字（文档按照语义分成的词语）文档id：包含这个关键字的文档（一行数据）

原创 MQ（仅供自己参考）

同步通讯的优缺点：优点：时效高，数据一致，过程简单缺点：耦合度高。性能下降。CPU等待资源的浪费。级联失败。2、异步通讯：异步调用常见的实现就是事件驱动模式异步的优缺点：优点：耦合度低 ，吞吐量提升 ，故障隔离（不在联机发生失败） ，流量削峰（Broker缓存事件，让其他服务慢慢来执行）缺点：依赖于Broker的可靠性、安全性、吞吐量架构复杂，没有明显的流程线，不好追踪管理一般的项目都是使用同步通讯，因为需要拿到其他服务的返回结果，而异步通讯只是通知他有事情要做，而不需要他返回结果。

原创 docker操作的基本命令加容器的基本命令（仅供自己参考）

容器内的数据可以到数据卷当中，数据卷中的数据也能到容器，这个交换是实时的）宿主机的目录挂载：这个挂载就是不在默认的数据卷存放路径了（/var/lib/docker/volumes/），这个路径可以是随意的，你想在哪里就在哪里。3、升级维护困难：当我们这个容器的版本过低要进行版本的更迭，那么旧版本上配置的数据在新的数据上不能复用（旧版本删除，配置的数据也随之删除了）。3、当你启动的时候，没有创建某个数据卷，但是你启动的时候又绑定了，那么这个数据卷在启动的时候就会自动创建。所有修改对新创建的容器是不可复用的。

原创 docker基本（仅供自己参考）

（2）：开发、测试、生产环境有差异（比如centos开发和测试的，上线的时候需要部署到ubutu上，那么两个linux环境的不同就会造成项目出现错误）由此可知：当我们在每个应用的容器中顺带打包了某个系统的函数库，那么我们就可以部署到任意的一台机器上，而不用管这个机器是那个操作系统了（内核相同就行）（1）：系统应用：每个系统都有自己的系统，每个系统应该的命令（函数）不同（导致部署项目系统之间的不兼容）（2）：内核：内核接收到每个系统的命令之后，将这些命令转化为相应的指令，这些指令就去操作计算机硬件。

原创 统一网关--gateway（仅供自己参考）

3、全局过滤器（GlobalFilter）：在已经有了一个default-filter全局的情况下为什么还需要这个全局的呢？两个的优缺点：zuul是基于servlet实现的阻塞式编程，而gateway是基于spring5提供的webflux实现的响应式的编程。（2）：服务路由（具体的业务路由到具体的服务），负载均衡（多台服务的话，服务之间进行负载均衡）4、过滤器的执行顺序，局部和默认过滤器的order值为1，如果下面有多个则依次增大。1、局部路由过滤器：（在相应路由的微服务生效）

原创 Fegin的基本（仅供自己参考）

service也需要api，controller也需要相同的api，将这个方法提出来写一个接口供他们两个使用。2、抽取：在controller层面将相应的请求的方法写好，然后打包。在其他的微服务只需要导包，然后调用相应的请求方法。）（在高版本的springboot中还需要加入一个负载均衡的依赖，有了这个依赖之后需要把ribbon排除）缺点：service和controller是紧耦合，并且service也需要写参数中的注解。2、Fegin是一个声明式的http客户端，其作用是优雅的帮我们发起http请求。

原创 Sping AOP

这些注解提供了灵活的方式来定义和管理 AOP 通知，允许开发者在方法执行的不同阶段插入自定义逻辑，从而实现横切关注点的处理，如日志、异常处理、性能监控等。

原创 Nacos配置管理

3、配置bootstrap.yml文件（配置的原因：因为项目一启动开始就去读nacos中的配置文件，而不是直接读取application.yml文件。这就导致在application.yml中配置的nacos中的路径和其他的都不能提前知道了。这就需要一个启动之后先获取nacos的配置的文件，之后去读nacos中的配置）1、配置的环境有很多，dev，test等等。因为这些环境的名称都相同，每个环境不同的只是后面的profiles。2、环境的优先级：不同的环境可以有相同的属性值，那么以哪个为准呢？

原创 Nocos的一些基本知识（仅供自己参考）

这个拉取是服务被动的拉取，当在一次拉取之后，还没有到下次拉取的时间的时候，如果有服务提供者挂了，则服务消费者不知道并主动的去请求服务提供者则会失败报错。一个程序更新完之后，首先将这个机器的服务启动，将其他机器的服务的权重设置为0。如果一个权重是1，一个是0.1，则第一个被访问的次数是第二个的十倍（当然这个前提是你在同一个集群当中，如果是不同的集群可能是不生效的）。当nacos中的服务列表发生变化，nacos会主动将服务的情况告诉服务消费者，而不是服务消费者等待到下次拉取的时候才知道。

原创 Ribbon负载均衡

过程：首先通过RestTemplate发起请求，负载均衡拦截器拦截请求，拿到名称user-server（"http://user-server/user/"）后，将名称发送到动态服务拦截器，动态服务拦截器通过与eureka服务注册中心交互，拿到名称为user-server的客户端ip和端口，返回的是一个列表。（1）：第一种bean：第一种bean是全局配置（就是一个微服务1里面，会请求其他的微服务，这个请求的数目很多，微服务1请求其他每种不同的微服务有不同的负载均衡方式，如：轮询，随机等等。

原创 Session 不共享（仅供自己参考）

在有多台的Tomcat实现并发的时候，在进行轮询使用Tomcat，在一台Tomcat登录之后，这个用户的sessionID存储在第一个Tomcat，但是当再有请求，另外一个Tomcat接受，但是Tomcat没有上一个Tomcat的保存的sessionId，就又需要登录，导致用户的体验感不好。所以采用redis保存用户的信息，因为每个Tomcat都可以访问redis，就可以实现信息的共享。

原创 Linux常用命令（仅供自己参考）

tail -f my.log :动态的获取日志，当更新了或者追加了 echo “内容”>> my.log, 就可以动态的获取日志中的内容。拷贝移动文件 source:文件源 dest:目标地址。echo 将后面这一句加到/etc/profile 文件后面。选项 -p ：是可以创建多层目录。删除目录和文件 （不为空也能删）source 重新加载文件内容。以分页形式查看文件内容。

原创 feed流（投喂）

优缺点：对于普通人，因为粉丝数量比较少，我们直接给他的粉丝推到粉丝的收件箱，不需要发件箱。所以大v的就直接放一个发件箱，对于普通的用户不做任何操作，但是对于活跃粉丝就需要将博客给推到他的收件箱。那么在第二次分页的时候，角标读取的不是5-1的数据，而是随着数据多了一个，读取的是6-2，那么就会造成第二次页数据和第一页数据有一个重复的数据6；滚动分页：通过记录一页中最后一个数据的id，第二页接着从这个数据的id的后面读取下一页的数据，这样就不会造成页与页之间的数据的重复了。优缺点：延迟低，耗时少。

原创 redis的分片集群（仅供自己参考）

前言：为什么使用分片集群：因为redis的主从和哨兵机制主要是用来解决redis的高并发读的问题，还有redis的高并发的写的问题没有解决。使用分片集群就可以很好的解决redis写的问题，有多个master就可以实现并发的写。2、分片集群的插槽：插槽的大小分为16384（2的14次方），如果有多个master，则每个集群各占这些插槽的均分。使用{}来进行分类，{it}a，{it}b都被分在同一个插槽里面，到时候不用频繁的切换master，可以减少因频繁切换带来的性能问题。还有单个节点的大小的问题。

原创 Redis哨兵机制

如果是主节点故障之后，那么哨兵就会从从节点中选一个来当主接主节点，判断的依据有很多，主要是看offset是否是最大的最接近故障的offset的值。选出来之后，就会执行slaveof no one，使这个从节点变为主节点，同时向存活的从节点发生信息，告知从节点，主节点发生变化。它是每隔1秒钟就向主从集群中的节点发送心跳，如果节点没有回复，则这个哨兵就主观的认为这个节点发生故障，这时候其他的哨兵也就向这个节点发送心跳，当有一半的哨兵主观的认为节点故障，那么就客观的认为这个节点不能工作了，发生故障。

原创 reids的全量同步和增量同步

（1）首先master和slave节点建立连接，连接之后，slave会向master发送增量同步（slave会携带自己的repid和offset），master接收了slave的增量同步请求之后，就会拿自身的replId和slave的replId进行判断，如果相同则进行增量同步，不相同则进行全量同步，之后master会将自己的replId和offset发送给slave。slave执行log文件，将数据补充完整，每当数据不一致的时候，都进行增量同步。

原创 微服务的技术栈

1、如下图：2、3、

原创 redis持久化AOF（仅供自己参考）

1、redis每处理一个命令都会在AOF中添加一条命令，如果redis不小心发生宕机，那么只需要执行这个命令文件AOF文件就可以恢复数据了。3、bgrewriteaof命令，是对AOF文件中的数据进行重写，对重复的命令执行一次，对相同的命令合并执行。减少AOF文件的大小。4、RDB和AOF结合使用，RDB主要用来异地容灾，AOF数据安全性较高。

原创 redis持久化RDB（仅供自己参考）

冲突的解决：在进行RDB的时候，主线程和子线程的读取不受任何影响，但是如果这个时候主线程有个写操作，那么如果直接在原数据上操作，那么就会和子进程的读取有冲突，解决方法：主线程会拷贝要修改的数据，得到数据的副本，同时将自己的页表的映射进行修改。解决了冲突带来了数据的不一致。共享的方式：在fork之后，子进程跟父进程几乎一模一样，那么父进程有的页表，子进程也有。（1）save命令：是直接占用主线程来执行持久化的（因为redis是单线程的，如果执行save命令，则其他命令，无论查询还是怎么的都被阻塞了）

原创 HyperLogLog

2、HyperLogLog（算法）（对于重复数据，只保存一个）1、uv和pv的区别。

原创 位运算和BitMap（位图）仅供自己参考

只要有一个对应的位是 1,结果位就是 1。只有两个都是0的时候才位0。只有当两个对应的位都是 1 时,结果位才是 1。&是只有两位都是1的时候才位1，其他的情况都为0。: 将一个数的二进制位向左移动指定的位数。（<<是有符号的左移），（<<<无符号的左移）（10<<1 == 20）（-10<< = -20）（>>有符号的右移），（>>>无符号的右移）（10>>1 = 5） (-10>>1 = )当两个对应的位相同时,结果位是 0。0和1为1,0和0为0,1和1为0。将 0 变成 1,将 1 变成 0。

原创 redis消息队列

确认消息命令：XACK key group ID [ID ...] （如果消息只是拿到，没有确认的话，消息会存放在expending-list里面）第二个sub接收的频道（order.*）接收order.后面所有的频道，使得两次pub发送的消息都接收到了。创建一个消费者组： XGROUP CREATE s1 g1 $ （s1队列名称，g1消费者组的名称）第一个sub接收的信息通道（order.p1）使得pub发送第二次消息没有接受到。$：则实时取数据，在消息存放的时候才会获取。

原创 redis redisson（仅供自己参考）

等待也不是死等（一直while循环），因为redis在释放一个键的时候，会发布一个通知，其他线程一直等待这个通过，有了通知之后，再次判断是否已经过了等待时间（设置的一个线程最长的等待时间，如果超出则获取锁失败）。为了解决这样的问题，给每一个获取锁的线程增加一个定时的任务（TimeOut），如果key释放的时间剩余key设置的释放时间的三分之一的话，就重新给key重新设置超时释放的值（这个值一直是原本的时间）。当主节点宕机，就会出现主节点的数据还没有同步到从节点，导致的一系列的问题。

原创 全局唯一id

由于一个单表存储的数量有限，那么就会用多个表存储，每个表的id都是自增，这样导致id不唯一的情况。由于数据库的自增的id很有规律，会让人猜到后续id。具体解决方法：使用redis的string自增方法。

原创 分布式锁（仅供自己参考）

分布式锁：满足分布式系统或集群式下多进程可见并且互斥的锁（使用外部的锁，因为如果是集群部署，每台服务器都有一个对应的tomcat，则每个tomcat的jvm就不同，锁对象就不同（加锁的机制，每个jvm有一个锁监听器，里面存放着是否含有所有加锁的对象。有一次线程来，首先判断该线程所具有的所要加锁的对象在锁监视器中是否有，有则让它等待，没有的话则将加锁的对象加进来，再有线程来判断，则和上面的流程一样））（自己理解的流程，可能不对，请指错）因为在加锁的时候new的不同的对象，使得每一个name都是不同的。

原创 超卖问题（仅供自己参考）

（2）：CAS使用要改变的字段（stock），通过在改变库存值的时候，看前面获取的stock值，和现在数据库中的stock值是否相同，相同就说明没有改变，不同则说明已经有其他线程已经改变了值。在一定的高并发的情况下，如果不加锁，干什么的，在我们判断最后的库存是否为0的时候，就会导致在库存为0之前，就有好多的线程拿到的库存是不为0之前的值，这就会导致库存的值在为0后还会修改。cas会导致很多数据失败（成功率很低）,因为这里使用的库存，我们直接使用当库存大于0的时候都可以修改，这样就可以使成功率上升。

原创 事务的范围比锁的范围大

原因：因为事务的范围比锁的范围大，当我们执行完这个方法，锁已经释放，由其他线程拿到这个锁来重新执行这段代码，但是这个时候，事务的内容还没有写入数据库，我们第二个锁进来判断数据库是否有值判断的肯定是为空，这第二个线程就会又进行插入，而不是进行修改。如果是在同一类当中，直接在加锁的地方调用这个类的另外一个方法（增加了事务的方法），这样是属于this调用。解决方法：在调用事务方法的地方加锁，这样保证锁的范围比事务的范围大。（1）：自己依赖自己，自己将自己自动注入。（2）：使用方法获取动态对象。

原创 spring xml实现bean对象（仅供自己参考）

原型（prototype）：通过设置scope属性，来指定bean的作用域为圆形模式，在自动注入的时候，bean容器会创建一个新的对象，把这个新的对象赋值给所需要的对象。单例（singleton）：通过设置scope属性，来指定bean的作用域为单例模式，也就是说，所有的对象注入都是用的bean容器中那唯一一个对象。Spring Bean生命周期大致可以分为以下 5 个阶段：1.Bean 的实例化、2.Bean 属性赋值、3.Bean 的初始化、4.Bean 的使用、5.Bean 的销毁。

原创 linux防火墙和mysql操作

原创 缓存穿透、缓存雪崩（仅供自己参考，勿看）

1.缓存空对象：在redis中保存null，设置短时间的过期时间（比如3-5）分钟，在有人恶意的用很多线程攻击的时候，可以在一定程度上缓解这个问题。如果新增一个新的id，id是前面在缓存和数据库都没有的id，而在解决缓存穿透的时候，在redis中设置了这个id为null，所以在（3-5分钟之内）会造成数据的短期的不一致。为了解决这个问题，在新增的时候，直接在redis中新增或者更新这个id的值。缓存穿透：表面理解，redis中没有，穿透redis，数据库没有，没有写回redis中。

原创 SortedSet常用命令 （仅供自己参考）

原创 缓存（仅供自己参考，勿看）

因为缓存速度读写速度高，所有在先选择操作数据库后删除缓存发生的概率低。对于主动更新策略1，对于如何选择线衫后操作，还是先操作后删的对比。并且需要满足一定的条件：在操作数据库的时候，缓存刚好过期了。