一、Kafka消费者组是什么？Consumer Group 是Kafka提供的可扩展且具有容错性的消费者机制。在组内多个消费者实例(Consumer Instance ),它们共享一个公共的ID即 Group ID 。组内的所有消费者协调在一起消费订阅主题（Subscribed Topics）的所有分区(Partition)。当然一个分区只能有同一个消费者组的一个Consumer 实例消费。Consumer Group 有三个特性： Consumer Group 下可以有一个或多个Consumer 实例。 这里的实例可以是一个单独的进程，也可以是同一进程下的线程； Group ID 是一个字符串， 在Kafka集群中唯一标识，Consumer Group； Consumer Group下所有实例订阅主体的单个分区，只能分配给组内某个Consumer实例消费。同一个分区消息可能被多个Group 消费。 二、Kafka消费者组解决了哪些问题？传统的消息系统中，有两种消息引擎模型：点对点模型（消息队列）、发布/订阅模型传统的两种消息系统各有优势，我们里对比一下： 传统的消息队列模型的缺 ...

举个例子在讲重排序之前，先来看一个例子： 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849package com.cyblogs.thread;import java.util.HashSet;import java.util.Set;/** * Created with leetcode-cn * * @Description: 验证重排序代码 * @Author: chenyuan * @Date: 2021/3/26 * @Time: 15:05 */public class VolatileSerialCase { static int x = 0, y = 0; static int a = 0, b = 0; public static void main(String[] args) throws InterruptedException { // 用set来保存数据，保证不会重复 Se ...

Paxos解决什么问题大家对Paxos的看法基本是“晦涩难懂”，虽然论文和网上文章也很多，但总觉得“云山雾罩”，也不知道其具体原理以及到底能解决什么问题。 究其原因，一方面是很多Paxos的资料都是在通过形式化的证明去论证算法的正确性，自然艰深晦涩；另一方面，基于Paxos的成熟工程实践并不多。本章试图由浅入深，从问题出发，一点点地深入Paxos的世界。 一个基本的并发问题先看一个基本的并发问题，如图116所示。假设有一个KV存储集群，三个客户端并发地向集群发送三个请求。请问，最后在get（X）的时候，X应该等于几？ 图116（K，V）集群多写答案是：X=1、X=3或X=5都是对的！但X=4是错的！因为从客户端角度来看，三个请求是并发的，但三个请求到达服务器的顺序是不确定的，所以最终三个结果都有可能。 这里有很关键的一点：把答案换一种说法，即如果最终集群的结果是X=1，那么当Client1发送X=1的时候，服务器返回X=1；当Client2发送X=3的时候，服务器返回X=1；当Client3发送X=5的时候，服务器返回X=1。相当于Client1的请求被接受了，Client2、Cli ...

Spring是一个非常优秀的开源项目，而且基本是互联网的标配。随着这几年的源码阅读习惯，有用一套自己的源码阅读笔记项目已经是水到渠成。今天就来在本地编译一份，以便于后面记录核心笔记用。 环境准备1.准备好源代码 https://spring.io/projects/spring-framework https://github.com/spring-projects/spring-framework https://gitee.com/mirrors/Spring-Framework (推荐，毕竟速度快，而且每天会跟github同步一次) https://gitee.com/vernon/Spring-Framework (为了自己可以提交代码，必须要fork一份) 为什么贴这些url地址，是因为提醒我们所有人，官网与github是我们最先关注的地方。 gradle.properties 12345version=5.3.5-SNAPSHOTorg.gradle.jvmargs=-Xmx1536Morg.gradle.caching=trueorg.gradle.parallel=t ...

二值状态统计这里的二值状态就是指集合元素的取值就只有 0 和 1 两种。在签到打卡的场景中，我们只用记录： 签到（1） 未签到（0） 所以它就是非常典型的二值状态，在签到统计时，每个用户一天的签到用 1 个 bit 位就能表示，一个月（假设是 31 天）的签到情况用 31 个 bit 位就可以，而一年的签到也只需要用 365 个 bit 位，根本不用太复杂的集合类型。 这个时候，我们就可以选择 Bitmap。这是 Redis 提供的扩展数据类型。我来给你解释一下它的实现原理。Bitmap 本身是用 String 类型作为底层数据结构实现的一种统计二值状态的数据类型。String 类型是会保存为二进制的字节数组，所以，Redis 就把字节数组的每个 bit 位利用起来，用来表示一个元素的二值状态。 你可以把 Bitmap 看作是一个 bit 数组。Bitmap 提供了 GETBIT/SETBIT 操作，使用一个偏移值 offset 对 bit 数组的某一个 bit 位进行读和写。不过，需要注意的是，Bitmap 的偏移量是从 0 开始算的，也就是说 offset 的最小值是 0。当使 ...

环境准备我们通过Docker快速的拉取一个环境，这样子对于学习来说成本比价低。直接参照https://hub.docker.com/r/mysql/mysql-server/ 来做就好了。 12345678910111213141516171819202122232425262728293031323334353637383940414243# 快速拉取一个mysql的image➜ ~ docker pull mysql/mysql-serverUsing default tag: latestlatest: Pulling from mysql/mysql-server501550cfd5c0: Pull completee0509d775110: Pull completed5a01765d011: Pull complete970507e942eb: Pull completeDigest: sha256:0bb21c0f1aa9296e7deafacec5703b80e4d923dfdfcaa2efbe0c8377a8592128Status: Downloaded newe ...

2020年，感觉真的是一个不平凡的年。是时间流逝非常快的一年，也是成长最快的一年。感谢身边所有的人~ 谈口罩还记得年初的时候，怕被疫情隔在家里了，正月初三就开车到了深圳。那时候听新闻说可能要带半年或者一年的口罩，当时感觉不可思议，根本不可能。现在一年已经已经过去了，但口罩还依然要继续…… 说到口罩，记得刚刚开始在老家带口罩的时候，家里好多人不理解，为什么要戴口罩？（估计跟很多老美一样，觉得不尊重，觉得自己没病等）到了“恐慌”的时候，家里人比我们更着急，更加上心。在这次疫情中，真的也是感受到了人间百态，看到了白衣天使的伟大，看到了一些黑心的商家，看到了那些平凡的人做着不平凡的事儿，感受到了近些年来祖国的伟大（非常感谢国内短视频）。 今年给我最大的感受是繁忙、成长、充实，总的来说是收获的一年吧。 写作与公众号年初的时候开启了我的个人公共账号「简栈文化」，一共发表了文章112篇，几乎全部都是跟技术相关的，在编写与梳理这些知识的时候，内心是充满热情与喜悦的。特别是大家去催更的时候，或者有问题请教你的时候，跟你讨论的时候，所有的熬夜与辛苦都是值得的，因为你获得的知识与朋友。后面也是因为工作原因， ...

发现问题今天本来是为了解决一个Apollo配置与Code同时变更不一致问题，我需要去通过SPI的方式去重写Apollo刷新Remote配置。所以，我就写一个很小的DEMO来验证每次变更Apollo配置对我服务端的取数。 1234567@Data@Componentpublic class MarketConfig { @Value("${market.test.chenyuan}") private String testName;} 对应在Apollo的配置 1market.test.name = Test1111 Controller层的代码 1234567@Resourceprivate MarketConfig marketConfig;@RequestMapping(value = "/sayHello", method = RequestMethod.POST)private String sayHello(){ // 注意，这里由于我的不小心写成了private return marketConfig ...

前奏MySQL 的默认事务隔离级别为 Repeatable Read。而 ORACLE、SQLServer 等的默认隔离级别使用的是 Read Committed 模式，为什么呢？ 开始我们的内容，相信大家一定遇到过下面的一个面试场景 面试官：“讲讲 mysql 有几个事务隔离级别？” 你：“读未提交，读已提交，可重复读，串行化四个！默认是可重复读”面试官：“为什么 mysql 选可重复读作为默认的隔离级别？”(你面露苦色，不知如何回答！)面试官:“你们项目中选了哪个隔离级别？为什么？”你：“当然是默认的可重复读，至于原因…呃…”(然后你就可以回去等通知了！) 为了避免上述尴尬的场景，请继续往下阅读！Mysql 默认的事务隔离级别是可重复读 (Repeatable Read)，那互联网项目中 Mysql 也是用默认隔离级别，不做修改么？OK，不是的，我们在项目中一般用读已提交 (Read Commited) 这个隔离级别！what！居然是读已提交，网上不是说这个隔离级别存在不可重复读和幻读问题么？不用管么？好，带着我们的疑问开始本文！ 我们先来思考一个问题，在 Oracle，Sql ...

首先，我们来看一下Eureka的架构图，有一个整体的认识。传送门：https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance Eureka核心功能服务注册 在微服务启动时，首先，服务提供者需要将自己的服务注册到服务注册中心，服务提供者在启动的时候会发送REST请求将自己注册到服务注册中心上，并带上一些元信息。服务注册中心接收到REST请求，会将元信息存储在一个双层Map中，第一层key是服务名，第二层key是具体服务的实例名。 注意：在服务注册时，需要确认一下eureka.client.register-with-eureka=true是否正确，如果为false是禁止向服务注册中心注册的。 服务同步 当服务成功的注册到了注册中心之后，由于注册中心可能是高可用的集群，那么我们的服务可能只注册到了一个集群中的一个注册中心上，被一个注册中心所维护，而不被另外一个注册中心所维护，那么这个时候，我们就需要将这个注册中心的信息同步给集群中其他的注册中心，这就叫服务同步。那么他是如何实现的呢？ 由于在集群中，一个注册中心互为其他注册中心的服务 ...