随着数据规模的不断膨胀，使用多节点集群的分布式方式逐渐成为趋势。在这种情况下，如何高效、自动化管理集群节点，实现不同节点的协同工作，配置一致性，状态一致性，高可用性，可观测性等，就成为一个重要的挑战。 集群管理的复杂性体现在，一方面我们需要把所有的节点，不管是底层数据库节点，还是中间件或者业务系统节点的状态都统一管理起来，并且能实时探测到最新的配置变动情况，进一步为集群的调控和调度提供依据。 另一方面，不同节点之间的统一协调，分库分表策略以及规则同步，也需要我们能够设计一套在分布式情况下，进行全局事件通知机制以及独占性操作的分布式协调锁机制。在这方面，ShardingJDBC采用了Zookeeper/Etcd来实现配置的同步，状态变更通知，以及分布式锁来控制排他操作。 ShardingJDBC分布式治理ShardingJDBC集成了Zookeeper/Etcd，用来实现ShardingJDBC的分布式治理，下面我们先通过一个应用程序来演示一下实现原理。 安装Zookeeper 通过这个地址下载Zookeeper https://mirrors.tuna.tsinghua.edu.cn/ ...

Sharding-JDBC 最早是当当网内部使用的一款分库分表框架，到2017年的时候才开始对外开源，这几年在大量社区贡献者的不断迭代下，功能也逐渐完善，现已更名为 ShardingSphere，2020年4⽉16⽇正式成为 Apache 软件基⾦会的顶级项⽬。 随着版本的不断更迭 ShardingSphere 的核心功能也变得多元化起来。如图7-1，ShardingSphere生态包含三款开源分布式数据库中间件解决方案，Sharding-JDBC、Sharding-Proxy、Sharding-Sidecar。 图7-1 Apache ShardingSphere 5.x 版本开始致力于提供可插拔架构，项目的功能组件能够灵活的以可插拔的方式进行扩展。 目前，数据分片、读写分离、数据加密、影子库压测等功能，以及对 MySQL、PostgreSQL、SQLServer、Oracle 等 SQL 与协议的支持，均通过插件的方式织入项目。 开发者能够像使用积木一样定制属于自己的独特系统。Apache ShardingSphere 目前已提供数十个 SPI 作为系统的扩展点，而且仍在不断增 ...

随着互联网的高速发展，带来了海量数据存储的问题，比如像物联网行业，每个智能终端每天进行数据采集和上报，每天能够产几千万甚至上亿的数据。在互联网电商行业，或者一些O2O平台，每天也能产生上千万的订单数据，这些量级的数据在传统的关系型数据库中已经无法支撑了，那么如何解决海量数据存储和计算等问题，在业内引入了分布式存储和分布式计算等解决方案，特别是NoSql的生态，我在前面讲过的k-v数据库、文档数据库、图形数据库等，都是比较主流的分布式数据库解决方案。 即便如此，关系型数据库仍然有它不可替代的特性，所以关系型数据库仍然是核心业务的基础数据平台，因此关系型数据库必然会面临数据量日益增长带来的海量数据处理问题。 Mysql数据库海量数据带来的性能问题目前几乎所有的互联网公司都是采用mysql这个开源数据库，根据阿里巴巴的《Java开发手册》上提到的，当单表行数超过500W行或者单表数据容量超过2G时，就会对查询性能产生较大影响，这个时候建议对表进行优化。 其实500W数据只是一个折中的值，具体的数据量和数据库服务器配置以及mysql配置有关，因为Mysql为了提升性能，会把表的索引装 ...

高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。 假设系统一直能够提供服务，我们说系统的可用性是100%。如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是99%。很多公司的高可用目标是4个9，也就是99.99%，这就意味着，系统的年停机时间为8.76个小时。 那么如何保证系统的高可用呢 首先，在整个架构的每个节点中，不允许存在单点问题，因为单点一定是高可用最大的风险点，我们应该在系统设计过程中去避免单点问题。 在实现方法上，一般采用的就是集群部署、或者冗余部署来实现。这样的设计使得如果某个节点出现故障，其他的节点还可以继续使用。 Redis中高可用设计的必要性Redis作为一个高性能Nosq中间件，会有很多热点数据存放在Redis中，一旦Redis-server出现故障，会导致所有相关业务访问都出现问题。另外，即便是设计了数据库兜底的方案，大量请求对数据库的访问也很容易导致数据库出现瓶颈，造成更大的灾难。 除此之外，Redis的集群部署还可以带来额外的收益： 负 ...

Redis的强劲性能很大程度上是由于它所有的数据都存储在内存中，当然如果redis重启或者服务器故障导致redis重启，所有存储在内存中的数据就会丢失。但是在某些情况下，我们希望Redis在重启后能够保证数据不会丢失。 将redis作为nosql数据库使用。 将Redis作为高效缓存服务器，缓存被击穿后对后端数据库层面的瞬时压力是特别大的，所有缓存同时失效可能会导致雪崩。 这时我们希望Redis能将数据从内存中以某种形式同步到硬盘上，使得重启后可以根据硬盘中的记录来恢复数据。 Redis支持两种方式的持久化，一种是RDB方式、另一种是AOF（append-only-file）方式，两种持久化方式可以单独使用其中一种，也可以将这两种方式结合使用。 RDB：根据指定的规则“定时”将内存中的数据存储在硬盘上， AOF：每次执行命令后将命令本身记录下来。 RDB模式RDB的持久化方式是通过快照（snapshotting）完成的，它是Redis默认的持久化方式，配置如下。 # save 3600 1# save 300 100# save 60 10000 Redis允许用户自定义 ...

本篇文章主要基于Redisson中实现的分布式锁机制继续进行展开，分析Redisson中的时间轮机制。 在前面分析的Redisson的分布式锁实现中，有一个Watch Dog机制来对锁键进行续约，代码如下: private void renewExpiration() { ExpirationEntry ee = EXPIRATION_RENEWAL_MAP.get(getEntryName()); if (ee == null) { return; } //用到了时间轮机制 Timeout task = commandExecutor.getConnectionManager().newTimeout(new TimerTask() { //添加一个任务到时间轮 //省略部分代码.... }, internalLockLeaseTime / 3, TimeUnit.MILLISECONDS);//每次间隔租期的1/3时间执行 ee.setTimeout(t ...

Redis的使用场景很多，本篇文章主要给大家分享一下Redis实现分布式锁机制的原理。 下面通过Redisson框架封装的分布式锁机制，来演示一下分布式锁的实现。 引入redisson依赖 <dependency> <groupId>org.redisson</groupId> <artifactId>redisson</artifactId> <version>3.16.0</version></dependency> 编写简单的测试代码 public class RedissonTest { private static RedissonClient redissonClient; static { Config config=new Config(); config.useSingleServer().setAddress("redis://192.168.221.128:6379"); ...

Redis使用起来很简单，但是在实际应用过程中，一定会碰到一些比较麻烦的问题，常见的问题有 redis和数据库数据的一致性 缓存雪崩 缓存穿透 热点数据发现 下面逐一来分析这些问题的原理及解决方案。 数据一致性针对读多写少的高并发场景，我们可以使用缓存来提升查询速度。当我们使用Redis作为缓存的时候，一般流程如图3-4所示。 如果数据在Redis存在，应用就可以直接从Redis拿到数据，不用访问数据库。 如果Redis里面没有，先到数据库查询，然后写入到Redis，再返回给应用。 图3-4 因为这些数据是很少修改的，所以在绝大部分的情况下可以命中缓存。但是，一旦被缓存的数据发生变化的时候，我们既要操作数据库的数据，也要操作Redis的数据，所以问题来了。现在我们有两种选择： 先操作Redis的数据再操作数据库的数据 先操作数据库的数据再操作Redis的数据 到底选哪一种？ 首先需要明确的是，不管选择哪一种方案， 我们肯定是希望两个操作要么都成功，要么都一个都不成功。不然就会发生Redis跟数据库的数据不一致的问题。但是，Redis的数据和数据库的数据是不可能通过事 ...

我们要在Java中操作Redis，怎么做呢？首先我们先来了解一下Redis Serialization Protocol(Redis序列化协议)，这个是Redis提供的一种，客户端和Redis服务端通信传输的编码协议，服务端收到罅隙ihou，会基于这个约定编码进行解码。 打开Wireshark工具，对VMnet8这个网络进行抓包 增加过滤条件 ip.dst_host==192.168.221.128 and tcp.port in {6379} 使用RDM工具连接到Redis Server进行key-value操作，比如执行 set name mic 通过Wireshark工具监控数据包内容，如图3-3所示，可以看到实际发出的数据包是： *3\r\n$3\r\nSET\r\n$4\r\nname\r\n$3\r\nmic 其中*3*代表参数个数，set name mic， 表示三个参数。 $3表示属性长度，$表示包含3个字符。 客户端和服务器发送的命令或数据一律以 \r\n （CRLF回车+换行）结尾。 图3-3 基于这样一个特性，我们可以 ...

如图所示，Redis中提供了9种不同的数据操作类型，他们分别代表了不同的数据存储结构。 图2-17 数据类型 String类型String类型是Redis用的较多的一个基本类型，也是最简单的一种类型，它和我们在Java中使用的字符类型什么太大区别，具体结构如图2-18所示。 图2-19 String常用操作指令常用炒作指令如图2-20所示，更多的指令查询：http://doc.redisfans.com/ 图2-20 String的实际存储结构学过C++的同学都知道，C++中没有String类型，而Redis又是基于C++来实现的，那么它是如何存储String类型的呢？ Redis并没有采用C语言的传统字符串表示方式（char*或者char[]），在Redis内部，String类型以int/SDS(simple dynamic string)作为结构存储，int用来存放整型数据，sds存放字节/字符串和浮点型数据。 在C的标准字符串结构下进行了封装，用来提升基本操作的性能，同时充分利用以后的C的标准库，简化实现。我们可以在redis的源码中【sds.h】中看到sds的结构如 ...