mf97532的博客

（1）服务提供者需要以某种形式提供服务调用相关的信息，包括但不限于服务接口定义、数据结构、或者中间态的服务定义文件。例如Facebook的 Thrift 框架的IDL文件，Web service的 WSDL 文件；服务的消费者需要通过一定的场景获取远程服务调用相关的信息。（2）远程代理对象：服务消费者用的服务实际是远程服务的本地代理，说白了就是通过动态代理来实现的。（3）序列化：毕竟是远程通信，需要将对象转化成二进制流进行传输。不同的RPC框架应用的场景不同，在序列化上也会采取不同的技术。（4）通信。

在讲解动态代理前我们先聊聊什么是静态代理。

前面引入游戏的例子是为了让大家生动地理解什么是序列化和反序列化。序列化是指将对象实例的状态存到存储媒体的过程反序列化是指将存储在存储媒体中的对象状态装换成对象的过程把对象转化为可传输的字节序列过程反序列化：把字节序列还原为对象的过程。

在单体架构中一个应用程序就是一个服务包，包内的模块通过函数方法相互调用，模型足够简单，根本没有服务注册和发现一说。在微服务架构中会将一个应用程序拆分为多个微服务，微服务会部署在不同的服务器、不同的容器、甚至多数据中心，微服务间要相互调用，服务注册和发现成为了一个不可或缺的组件。

如下检查清单，帮助你在遇到 Redis 性能变慢的时候能高效解决问题。获取当前 Redis 的基线性能；开启慢指令监控，定位慢指令导致的问题；找到慢指令，使用 scan 的方式；将实例的数据大小控制在 2-4GB，避免主从复制加载过大 RDB 文件而阻塞；禁用内存大页，采用了内存大页，生成 RDB 期间，即使客户端修改的数据只有 50B 的数据，Redis 需要复制 2MB 的大页。当写的指令比较多的时候就会导致大量的拷贝，导致性能变慢。Redis 使用的内存是否过大导致 swap；

内存其实就是一块连续的空间，可以看做一个大数组，这块空间在业务运行时，经常会或零散或整齐的分布一些大大小小的对象，怎么样高效的分配和回收这块空间，同时尽量不影响业务系统的运行，就是 GC 垃圾回收要做的事，学习了七种基本的 GC 算法之后，我们更加知道，工程技术中没有“银弹”，没有完美无缺的算法，只有最适合自己业务系统的解法。

本节主要讲了实现IOC的几个核心的组件BeanFactory及其接口体系：BeanDefinition及其相关组件：BeanDefinitionReader和ClassPathBeanDefinitionScanner：读取资源，生成BeanDefinitionBeanDefinitionRegistry：存储BeanDefinitionBeanFactory核心实现：DefaultListableBeanFactory：IOC容器，同时实现了BeanDefinitionRegistry接口。

系统采用什么样的应用架构，则受到业务复杂度的影响，包括企业的发展阶段和业务特点；业务的复杂度（包括业务量大）必然带来技术的复杂度，应用架构的目标是在解决业务复杂度的同时避免技术太复杂，确保业务架构落地。技术架构：确定组成应用系统的实际运行组件（lvs，nginx，tomcat，php-fpm 等），这些运行组件之间的关系，以及部署到硬件的策略。对需求全盘理解之后，进行高度的抽象分类，然后对各个分类进行对应的产品设计，完成抽象的逻辑梳理和数据梳理，逻辑和数据最终组成一个有机体，成为产品架构。

上了微服务之后，很多原本很简单的问题现在都变复杂了，例如全局 ID 这事！最近工作中刚好用到这块内容，于是调研了市面上几种常见的全局 ID 生成策略，稍微做了一下对比，供小伙伴们参考。当数据库分库分表之后，原本的主键自增就不方便继续使用了，需要找到一个新的合适的方案。接下来我们一起来捋一捋。

总结一下，我们是如何从 0 到 1，再从 1 到 N 构建一个稳定、高性能的 Redis 集群的，从这之中你可以清晰地看到 Redis 架构演进的整个过程。数据怕丢失：持久化（RDB/AOF）主从副本（副本随时可切）故障手动切换慢：哨兵集群（自动切换）读存在压力：扩容副本（读写分离）写存在压力/容量瓶颈：分片集群分片集群社区方案：Twemproxy、Codis（Redis 节点之间无通信，需要部署哨兵，可横向扩容）分片集群官方方案。

幂等是一个数学与计算机科学概念。。比如求绝对值的函数，就是幂等的，。计算机科学中，幂等表示一次和多次请求某一个资源应该具有同样的副作用，或者说，多次请求所产生的影响与一次请求执行的影响效果相同。

好了，总结一下。这篇文章我们从「Redis 能否用作队列」这个角度出发，介绍了 List、Pub/Sub、Stream 在做队列的使用方式，以及它们各自的优劣。之后又把 Redis 和专业的消息队列中间件做对比，发现 Redis 的不足之处。最后，我们得出 Redis 做队列的合适场景。这里我也列了一个表格，总结了它们各自的优缺点。

领域建模的优秀与否，可以说直接决定着本次设计的成败，因为一旦发生建模边界不清晰，实体划分错乱，核心属性没有遵守开闭原则等问题，虽然当下可以正常交付业务，但是对于整个项目的后续发展可以说是灾难性的（之前接触过一个系统，因为一个实体的关键属性在最初设计时，没有制定标准规范，语义不统一，造成使用混乱。文章的前面部分，我讲了许多的概念：聚合根、值对象、领域事件、限界上下文等，但是实际设计开发过程中，并不需要照搬全套的体现出来，只要能够表达清楚核心的实体和关系、清晰的边界和合理的扩展性即是好的领域设计。

这部分在一定程度上是我的强迫症作祟，我关于文章对知识点讲解的完备性上对自己近乎苛刻。我觉得把Socket讲明白对接下来的讲解是一件很重要的事情，看过我之前的文章的读者或许能意识到，我尽量避免把前置知识直接以链接的形式展示出来，我认为会割裂整篇文章的阅读体验。不割裂的结果就是文章可能显得很啰嗦，好像一件事情非得从盘古开天辟地开始讲起。因此，如果各位觉得对这个知识点有足够的把握，就直接略过好了～我们所做的任何需要和远程设备进行交互的操作，并非是操作软件本身进行的数据通信。

WAL，中文全称是Write-Ahead Logging，它的关键点就是日志先写内存，再写磁盘。MySQL执行更新操作后，在真正把数据写入到磁盘前，先记录日志。好处是不用每一次操作都实时把数据写盘，就算crash后也可以通过redo log恢复，所以能够实现快速响应SQL语句。其实所谓的两阶段就是把一个事务分成两个阶段来提交。两阶段提交两阶段提交主要有三步曲：redo log在写入后，进入prepare状态执行器写入bin log进入commit状态，事务可以提交。为什么需要两阶段提交呢?

最近是又喜又忧，喜的是业务量发展猛增，忧的是由于业务量猛增，一些原来不是问题的问题变成了大问题，比如说新会员注册吧，原来注册成功只要发个短信就行了，但随着业务的发展，现在注册成功也需要发 push，发优惠券,…等这样光注册用户这一步就需要调用很多服务，导致用户注册都需要花不少时间，假设每个服务调用需要 50 ms，那么光以上服务就需要调用 200 ms，而且后续产品还有可能再加一些等活动，每加一个功能，除了引入额外的服务增加耗时外，还需要额外集成服务，重发代码，实在让人烦不胜烦，张大胖想一劳永逸地解决这个问

在测试案例对比中，时间耗时的顺序为 Pzstd < ISA-L < Pigz < LZ 4 < Zstd < Brotli < Gzip （排名越靠前越好），其中压缩和解压缩的时间在整体的耗时上占比较大，因此备选策略为 Pzstd、ISA-L、Pigz。详细的测试过程和方案对比可以参考原文：《速度与压缩比如何兼得？压缩算法在构建部署中的优化》9.3 小结。

好了，总结一下，这篇文章我们主要讲了 Redis 在「命令使用」、「数据持久化」、「主从同步」3 个方面可能存在的「坑」。怎么样？有没有颠覆你的认知呢？这篇文章信息量还是比较大的，如果你现在的思维已经有些「凌乱」了，别急，我也给你准备好了思维导图，方便你更好地理解和记忆。希望你在使用 Redis 时，可以提前规避这些坑，让 Redis 更好地提供服务。

传统的ELK方案是一种滞后的业务追踪，需要事后从大量离散的日志中搜集和筛选出需要的日志，并人工进行日志的串联分析，其过程必然耗时耗力。而分布式会话跟踪方案则是在调用执行的同时，实时地完成了链路的动态串联，但由于是会话级别且仅关注于调用关系等问题，导致其无法很好地应用于业务追踪。因此，无论是传统的ELK方案还是分布式会话跟踪方案，都难以满足日益复杂的业务追踪需求。

你知道是高可用的基石，某个 slave 宕机依然可以将请求发送给 master 或者其他 slave，但是如果 master 宕机，则只能响应读操作，写请求无法再执行。所以主从复制架构面临一个严峻问题：master 宕机，无法执行写操作，无法自动选择将一个 slave 切换为 master，也就是无法实现自动故障切换。Chaya：“还记得那晚我与男友约会，眼前是橡树的绿叶，白色的竹篱笆。好想告诉我的他，这里像幅画，一起手牵手么么哒（此处省略 10000 字）。

不推荐在这种CPU使用过高的情况下进行慢日志的开启。因为大量的请求，如果真是慢日志问题会发生日志磁盘写入，性能贼低。直接通过MySQL show processlist命令查看，基本能清晰的定位出部分查询问题严重的SQL语句，在针对该SQL语句进行分析。一般可能就是索引、锁、查询大量字段、大表等问题导致。再则一定要使用缓存系统，降低对MySQL的查询频次。对于内存调优，也是一种解决方案。

在传统IO中，如果想将用户缓存区的数据放到内核缓冲区，需要经过CPU拷贝而基于零拷贝技术可以减少CPU拷贝次数，常见的有两种：mmap()sendfile()mmap()是将用户缓冲区和内核缓冲区共享，操作用户缓冲区就好像直接操作内核缓冲区，读写数据时不需要CPU拷贝Java中可以使用MappedByteBuffer这个API来达到操作内核缓冲区的效果sendfile()主要是用于文件传输，可以通过sendfile()将一个文件内容传输到另一个文件中或者是网络中。

synchronized，是解决并发情况下数据同步访问问题的一把利刃。那么synchronized的底层原理是什么呢？下面我们来一层一层剥开它的心，就像剥洋葱一样，看个究竟。同步代码块是通过monitorenter和monitorexit来实现，当线程执行到monitorenter的时候要先获得monitor锁，才能执行后面的方法。当线程执行到monitorexit的时候则要释放锁。

陈某提示：大家介绍场景的时候，就说自己主要涉及了两个场景， Java进程飙升900%、MySQL进程飙升900%两种场景，其实，这两个场景就足够讲半天了， 其他的，使用规避技巧规避一下就行。转换后的结果分别为7665，由于导出的线程快照中线程的nid是16进制的，而16进制以0x开头，所以对应的16进制的线程号nid为0x7665。但是，一旦高并发场景，要么走到了死循环，要么就是在做大量的 GC, 容易出现这种 CPU 飙升的情况，CPU飙升900%，是完全有可能的。目测数据量不大，也就几百万条而已。

其实，mysql主从相关的八股文考点，还有很多，比如数据库主从延迟的原因与解决方案有哪些?MySQL是怎么保证主从一致的等等，你们知道怎么回答嘛？

有朋友去字节面试。？其实这不就送分题嘛，哈哈~~ 我梳理了一下答案：批量处理思想磁盘顺序读写零拷贝技术页缓存加速消息读写分区与并行处理数据压缩。

elastic Search, 也就是 es，是一个开源的搜索引擎。它介于应用和数据之间，只要将数据写入 es，应用就可以通过一些关键词搜索到数据。效果就像某度搜索一样。那它是怎么做到的呢？我们从倒排索引聊起。回到文章开头的例子。依次遍历文本匹配是否含有"xiaobai"，确实低效。那有更高效的解法吗？有，我们可以对文本进行切分，比如"I like xiaobai"切分为"I"、"like"、"xiaobai"三部分，这个操作叫分词，分词后的每部分，我们称为一个词项，也就是term。

如果插入关键字后，叶子节点当前含有的关键字数目等于阶数m，则插，该节点开始「分裂」为两个新的节点，一个节点包含⌊m/2⌋ 个关键字，另外一个关键字包含⌈m/2⌉个关键值。最后插入28，发现当前节点关键字也是不小于阶数4了，于是分裂，于是分裂， 第 ⌈4/2⌉=2个，也就是36上移到父节点，因父子节点只有2个关键值，还是小于4的，所以不用继续分裂，插入完成。将主键索引树的磁盘块3加载内存，在内存遍历，找到id=400的记录，拿到R4这一行的数据，好的，大功告成。分裂后，需要将⌈m/2⌉的关键字上移到父结点。

这种方案的核心逻辑就是，创建一个在线用户身份集合为key，利用用户身份为member，利用过期时间为score，然后对这个集合进行增删改查，实现起来还是比较巧妙和简单的，大家有兴趣可以试试看。如果网站是公开的，是那种不需要登录就可以浏览的，那么这种网站一般就需要自定一个规则来识别用户，也有很多方式实现如IP、deviceId、浏览器指纹，推荐使用浏览器指纹的方式实现。我这里的逻辑是：每次添加一个在线用户时，利用当前时间加上过期时间计算出一个分数，可以有效保证当前用户只会存在一个最新的登录态。

在使用 MyBatis 开发项目时，Mapper 接口是为数据库操作提供最直观的方法，但在实现方式上，我们有两种选择：全注解模式和混合模式。那么，他们有什么区别，应该如何选择？我们一起来讨论一下。

在深入隔离级别之前，我们必须先统一共识：什么是事务？为什么需要它？事务是数据库操作的一个最小逻辑工作单元，其内的所有操作要么全部成功，要么全部失败。一个经典的例子就是银行转账：从 A 账户扣款和向 B 账户加款，这两个操作必须作为一个整体，不能分割。原子性 (Atomicity)： 事务是一个不可分割的整体，就像原子一样。它要么全部完成，要么全部不完成，不存在中间状态。InnoDB 通过Undo Log来实现原子性。如果事务失败，Undo Log 会将已经修改的数据恢复到事务开始前的状态。

在传统IO中，如果想将用户缓存区的数据放到内核缓冲区，需要经过CPU拷贝而基于零拷贝技术可以减少CPU拷贝次数，常见的有两种：mmap()sendfile()mmap()是将用户缓冲区和内核缓冲区共享，操作用户缓冲区就好像直接操作内核缓冲区，读写数据时不需要CPU拷贝Java中可以使用MappedByteBuffer这个API来达到操作内核缓冲区的效果sendfile()主要是用于文件传输，可以通过sendfile()将一个文件内容传输到另一个文件中或者是网络中。

学了这么多，相信大家对缓存更新的策略都已经有了清晰的认识。最后稍稍总结一下。缓存更新的策略主要分为三种：Cache aside 通常会先更新数据库，然后再删除缓存，为了兜底通常还会将数据设置缓存时间。Read/Write through 一般是由一个 Cache Provider 对外提供读写操作，应用程序不用感知操作的是缓存还是数据库。Write behind简单理解就是延迟写入，Cache Provider 每隔一段时间会批量输入数据库，优点是应用程序写入速度非常快。

PS:这是多年黄历的老八股了，一定要理解清楚。

微服务（Microservices）是一种软件架构风格，将一个大型应用程序划分为一组小型、自治且松耦合的服务。每个微服务负责执行特定的业务功能，并通过轻量级通信机制（如HTTP）相互协作。每个微服务可以独立开发、部署和扩展，使得应用程序更加灵活、可伸缩和可维护。在微服务的架构演进中，一般可能会存在这样的演进方向：单体式-->服务化-->微服务。单体服务（Monolithic Service）是一种传统的软件架构方式，将整个应用程序作为一个单一的、紧耦合的单元进行开发和部署。

相信很多后端开发的伙伴们，都做过刷数任务了吧。今天跟大家聊聊，做好一个刷数任务，需要具备哪些。

零拷贝字面上的意思包括两个，“零”和“拷贝”：“拷贝”：就是指数据从一个存储区域转移到另一个存储区域。“零” ：表示次数为0，它表示拷贝数据的次数为0。合起来，那零拷贝就是不需要将数据从一个存储区域复制到另一个存储区域咯。零拷贝是指计算机执行IO操作时，CPU不需要将数据从一个存储区域复制到另一个存储区域，从而可以减少上下文切换以及CPU的拷贝时间。它是一种I/O操作优化技术。如果进程运行于内核空间，被称为进程的内核态如果进程运行于用户空间，被称为进程的用户态。什么是CPU上下文？

我们都知道加密后长度会增长，增长的这部分长度存储就是我们要花费的额外成本，典型的使用成本来换取速度，密文增长的幅度随着算法不同而不同以DES举例，13800138000加密前占11个字节，加密后的串HE9T75xNx6c5yLmS5l4r6Q==占24个字节，增长是2.18倍，所以一个优秀的算法是多么的重要，能为公司节省不少成本，但是话又说回来算法工程师的工资也不低，所以我也不知道是节省成本还是增加成本，哈哈哈…treeId=1&articleId=106213&docType=1。

<title>实时监控</title>

B+树叶子和非叶子结点的数据页都是16k，且数据结构一致，区别在于叶子节点放的是真实的行数据，而非叶子结点放的是主键和下一个页的地址。B+树一般有两到三层，由于其高扇出，三层就能支持2kw以上的数据，且一次查询最多1~3次磁盘IO，性能也还行。存储同样量级的数据，B树比B+树层级更高，因此磁盘IO也更多，所以B+树更适合成为mysql索引。索引结构不会影响单表最大行数，2kw也只是推荐值，超过了这个值可能会导致B+树层级更高，影响查询性能。单表最大值还受主键大小和磁盘大小限制。