男儿当自强

xxl-job 调度中心HA方案

JWT：JSON Web Token，是通过数字签名，以JSON对象为载体在服务间安全传输信息的方式。JWT由三部分组成：头信息、有效载体和签名。头信息包括：令牌类型和签名算法信息；有效载体是使用一个JSON对象作为数据内容，由于只是采用base64运算，并没有进行加密，因此通常存放一些非敏感数据；签名是采用不可逆签名算法对base64后的头信息拼接上点拼接上base64后的有效载体及签名秘钥进行运算得出，防止token信息被篡改，最后生成的Token是由base64后的头信息拼接上点拼接上base64后的

系统架构客户端发起秒杀请求，请求经网关处理转发到对应的服务节点上，进行业务层处理，最后数据入库。业务处理： 验证秒杀活动是否已经开启； 对流量进行限制； 验证订单信息（验证重复秒杀、验证库存是否足够）； 订单数据异步入库；验证秒杀活动是否开启，需要用到Redis实现，因为服务是分布式的，多个节点上的系统时间可能存在略微差异，可以采用Redis来管理秒杀活动的开启状态。由于秒杀开启后，会有大量流量进入，需要对访问流量进...

布隆过滤器是一种数据结构，由一个很长的二进制位数组和一系列随机映射函数组成，用于判断某个key一定不存在或者可能存在于某个集合中，它在存储空间占用和查询效率上非常有优势，但是存在一定的误算率，数据越多误算率越高。 当使用布隆过滤初始化一个key时，先对key使用一系列的映射函数映射后得出它在二进制数组中的一系列位置，然后把这些位置上的值设置为1。当进行查找时，同样对key使用一系列的映射函数进行映射得出它在数组中的一系列位置，如果这些位置上存在为0的值说明key一定不在集合...

SnowFlake 算法，是 Twitter 开源的分布式 id 生成算法。其核心思想就是：使用一个 64 bit 的 long 型的数字作为全局唯一 id。在分布式系统中的应用十分广泛，且ID 引入了时间戳，基本上保持自增的，后面的代码中有详细的注解。这 64 个 bit 中，其中 1 个 bit 是不用的，然后用其中的 41 bit 作为毫秒数，用 10 bit 作为工作机器 id，12 bit 作为序列号。给大家举个例子吧，比如下面那个 64 bit 的 long 型数字：第一个部

过期删除策略删除到达过期时间的 key 。第一种：定时检查删除对于每一个设置了过期时间的 key 都会创建一个定时器，一旦达到过期时间都会删除。这种方式立即清除过期数据，对内存比较好，但是有缺点是：占用了大量 CPU 的资源去处理过期数据，会影响 redis 的吞吐量 和 响应时间。第二种：惰性检查删除当访问一个 key 的时候，才会判断该 key 是否过期，如果过期就删除。该方式能最大限度节省 CPU 的资源。但是对内存不太好，有一种比较极端的情况：出现大量的过期 key 没有

定期删除redis 会将每个设置了过期时间的 key 放入到一个独立的字典中，以后会定期遍历这个字典来删除到期的 key。Redis 默认会每秒进行十次过期扫描（100ms一次），过期扫描不会遍历过期字典中所有的 key，而是采用了一种简单的贪心策略。从过期字典中随机 20 个 key；删除这 20 个 key 中已经过期的 key；如果过期的 key 比率超过 1/4，那就重复步骤 1；redis默认是每隔 100ms就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。注

安装Redis下载Redis源码包到安装目录解压：# 解压 tar -zxvf redis-6.2.6.tar.gz# 进入解压后的redis目录cd redis-6.2.6安装gccyum install gcc-c++ -y执行编译make MALLOC=libc安装make install安装完成，为了方便使用可以拷贝常用的配置和脚本到指定目录[root@localhost redis]# mkdir bin[ro...

Redsi主从架构中，从节点可以分摊主节点的读取压力，并且当主机点宕机后可以让从节点充当主节点，实现故障转移，但是普通的主从架构故障转移不是自动完成的，需要手工处理。手工模拟故障转移：创建一个一主两从的主机架构：# 启动3个redis节点 （端口：6379 6380 6381）[root@localhost redis]# ./redis-server 6379/redis.conf[root@localhost redis]# ./redis-server 6380/redis.conf

一、Redis基本概念 面试官心理： 靠！手上活都没干完又叫我过来面试，这不耽误我事么，今儿又得加班补活了........咦，这小伙子简历不错啊，先考考它redis.......... 面试官： 谈谈你对Redis的理解？ 我： Redis是 ANSI C 语言编写的一个基于内存的高性能键值对（key-value）的NoSQL数据库，一般用于架设在Java程序与数据库之间用作缓存层来弥补DB性能与Java程序之间的差距所带来的请求阻塞造成的响应缓慢以及DB并发吞吐跟不上系统

Redis的主从复制是面试中经常会被问的，我最近面试的几家公司只要聊到Redis，都会问我主从复制的原理。1.为什么需要主从复制？在本系列的上一篇博客中，我们讲到了Redis的持久化机制，它很好的解决了单台Redis服务器由于意外情况导致Redis服务器进程退出或者Redis服务器宕机而造成的数据丢失问题。但持久化机制还原数据有个前提：你的Redis服务器得能正常启动。如果遇到极端的断电情况（虽然概率小，但是有可能），Redis服务器启都启动不了，怎么还原数据？怎么保证它的高可用。就算R

简单实现获取锁流程如下：setnx 如果key不存在，设置值成功，否则设置失败；setex 设置值附带过期时间；关键代码： <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> .

一、事务的四大特性关系型数据库的事务具有四个特性：1. 原子性2. 一致性3. 隔离性4. 持久性二、而在我们redis数据库中，事务回事什么样子的呢？首先我们给出一个定义：redis的事务中，一次执行多条命令，本质是一组命令的集合，一个事务中所有的命令将被序列化，即按顺序执行而不会被其他命令插入在redis中，事务的作用就是在一个队列中一次性、顺序性、排他性的执行一系列的命令。事务的生命周期：1. 事务的创建：使用MULTI开启一个事务2. 加入队列：在开启事务

JMM java内存模型，它是在多线程访问共享数据时，提供原子性、可见性有序性的规则和保障。原子性原子性：一个原子性操作可以包含一条或多条指令，一个原子性操作中的所有指令要么都不执行，要么全部执行且不会收到其他线程操作的影响。package com.tech.jmm;/** * @author lw * @since 2021/12/6 */public class A { static int i=0; static Object o=new Object()

解释器逐行将字节码解释成机器码，交由CPU执行。即时编译器，针对与热点代码也就是反复执行的代码进行优化编译，将字节码解释成机器码，保存在codeCache中，当下次执行时直接在codeCache获取，不用再进行编译性能提升。即时编译器分为C1及即时编译器和C2即时编译器，C1即时编译器采集程序的运行状态数据，进行编译优化，C2即时编译器在C1即时编译器上层彻底进行优化，C2即时编译器的优化性能高于C1即时编译器，C1即时编译器性能高于解释器。 即时编译器在优化编译时做出的优...

package com.tech.load.def;/** * @author lw * @since 2021/12/3 */public class UserImpl { static { System.out.println("UserImpl init ..."); }}package com.tech.load.def;/** * @author lw * @since 2021/12/3 */public class De..

类加载器是分级的，自上而下是：BootstrapClassLoader 启动类加载器，加载java_home/jre/lib下的类，由c++编写，不能通过java程序直接获取。 ExtensionClassLoader 扩展类加载器，加载java_home/jre/lib/ext下的类。 ApplicationClassLoader 应用程序类加载器，加载classpath下的类。 自定义类加载器 加载自义定路径下的类。当加载一个类时，先询问直接上级类加载器，是否加载过这个类，如果加载过那么类加

类加载过程：加载、连接和初始化，类的初始化是调用的类的构造方法cinit来完成的，JVM保证了类的构造方法在执行时的线程安全。类的初始化在一定的条件下会触发，它是懒惰的：触发类的初始化的条件：通过new创建类的对象 通过Class.forName创建类的类型对象 首次访问带static修饰的静态变量或静态方法（static final修饰的string类型或基本类型变量除外） 子类在初始化时先对父类初始化 通过子类访问父类的静态变量（static final修饰的string类型或基本类

为什么在RocketMQ和kafka中选型在单机同步发送的场景下，Kafka>RocketMQ，Kafka的吞吐量高达17.3w/s，RocketMQ吞吐量在11.6w/s。kafka高性能原因生产者Kafka会把收到的消息都写入到硬盘中，它绝对不会丢失数据。为了优化写入速度Kafak采用了两个技术，顺序写入和MMFile。顺序写入因为硬盘是机械结构，每次读写都会寻址->写入，其中寻址是一个“机械动作”，它是最耗时的。所以硬盘最“讨厌”随机I/O，最喜欢顺序I/O。为了提

概述 其实一直想写一篇rocketMq和kafka在架构设计上的差别，但是一直有个问题没搞明白所以迟迟没动手，今天无意中听人点播了一下似乎明白了这个问题，所以就有了这篇对比。 这篇博文主要讲清楚kafka和rocketMq的两个不同点，1、rocketMq的namesvr和kafka的zookeeper对比；2、kafka为什么比rocketMq有更大的吞吐量。如果能够讲清楚上面两个问题我觉得就已经很满足了。 最后，文章引入的参考文章里面有一些比较好的链接，有兴趣的话可以好好看...