跟着Mic学架构

我们一直说Redis的性能很快，那为什么快？Redis为了达到性能最大化，做了哪些方面的优化呢？在深度解析Redis的数据结构这篇文章中，其实从数据结构上分析了Redis性能高的一方面原因。在目前的k-v数据库的技术选型中，Redis几乎是首选的用来实现高性能缓存的方案，它的性能有多快呢？根据官方的基准测试数据，一台普通硬件配置的Linux机器上运行单个Redis实例，处理简单命令（O(n)或者O（logn）），QPS可以达到8W，如果使用pipeline批处理功能，QPS最高可以达到10W。Re

如图所示，表示发起一个请求时，涉及到数据库的相关操作，在前面的文章中我们说过，如果服务端要提升整体的吞吐量，就必须要减少每一次请求的处理时长，那么在当前这个场景中，数据库层面哪些因素会影响到性能呢？图2-1池化技术，减少频繁创建数据库连接遇到这样的问题，解决办法就是顺着当前整体的逻辑去思考，首先，应用要和数据库打交道，必然会设计到数据库链接的建立。然后在当前连接中完成数据库的相关操作，最后再关闭连接。在这种场景下，客户端每次发起请求，都需要重新建立连接，如果频繁的创建连接是否会影响到性能呢？答

Redis数据类型说明如图2-17所示，Redis中提供了9种不同的数据操作类型，他们分别代表了不同的数据存储结构。图2-17 数据类型String类型String类型是Redis用的较多的一个基本类型，也是最简单的一种类型，它和我们在Java中使用的字符类型什么太大区别，具体结构如图2-18所示。图2-19String常用操作指令常用炒作指令如图2-20所示，更多的指令查询：http://doc.redisfans.com/图2-20String的实际存储结构学过C++的同

Java中那些Redis的客户端前面我们的所有操作都是基于redis-cli来完成的，那么我们要在Java中操作Redis，怎么做呢？首先我们先来了解一下Redis Serialization Protocol(Redis序列化协议)，这个是Redis提供的一种，客户端和Redis服务端通信传输的编码协议，服务端收到罅隙ihou，会基于这个约定编码进行解码。打开Wireshark工具，对VMnet8这个网络进行抓包增加过滤条件ip.dst_host==192.168.221.128 and tc

Redis使用过程中要注意的事项Redis使用起来很简单，但是在实际应用过程中，一定会碰到一些比较麻烦的问题，常见的问题有redis和数据库数据的一致性缓存雪崩缓存穿透热点数据发现下面逐一来分析这些问题的原理及解决方案。数据一致性针对读多写少的高并发场景，我们可以使用缓存来提升查询速度。当我们使用Redis作为缓存的时候，一般流程如图3-4所示。如果数据在Redis存在，应用就可以直接从Redis拿到数据，不用访问数据库。如果Redis里面没有，先到数据库查询，然后写入到Redis

Redis实现分布式锁的原理前面讲了Redis在实际业务场景中的应用，那么下面再来了解一下Redisson功能性场景的应用，也就是大家经常使用的分布式锁的实现场景。引入redisson依赖<dependency> <groupId>org.redisson</groupId> <artifactId>redisson</artifactId> <version>3.16.0</version>

本篇文章主要基于Redisson中实现的分布式锁机制继续进行展开，分析Redisson中的时间轮机制。在前面分析的Redisson的分布式锁实现中，有一个Watch Dog机制来对锁键进行续约，代码如下:private void renewExpiration() { ExpirationEntry ee = EXPIRATION_RENEWAL_MAP.get(getEntryName()); if (ee == null) { return; } //

Redis的强劲性能很大程度上是由于它所有的数据都存储在内存中，当然如果redis重启或者服务器故障导致redis重启，所有存储在内存中的数据就会丢失。但是在某些情况下，我们希望Redis在重启后能够保证数据不会丢失。将redis作为nosql数据库使用。将Redis作为高效缓存服务器，缓存被击穿后对后端数据库层面的瞬时压力是特别大的，所有缓存同时失效可能会导致雪崩。这时我们希望Redis能将数据从内存中以某种形式同步到硬盘上，使得重启后可以根据硬盘中的记录来恢复数据。Redis支持两种方式

高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。假设系统一直能够提供服务，我们说系统的可用性是100%。如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是99%。很多公司的高可用目标是4个9，也就是99.99%，这就意味着，系统的年停机时间为8.76个小时。那么如何保证系统的高可用呢首先，在整个架构的每个节点中，不允许存在单点问题，因为单点一定是高可用最大的风险点，我们应该在系统设

随着互联网的高速发展，带来了海量数据存储的问题，比如像物联网行业，每个智能终端每天进行数据采集和上报，每天能够产几千万甚至上亿的数据。在互联网电商行业，或者一些O2O平台，每天也能产生上千万的订单数据，这些量级的数据在传统的关系型数据库中已经无法支撑了，那么如何解决海量数据存储和计算等问题，在业内引入了分布式存储和分布式计算等解决方案，特别是NoSql的生态，我在前面讲过的k-v数据库、文档数据库、图形数据库等，都是比较主流的分布式数据库解决方案。 即便如此，关系型数据库仍然有它不可替代的特性，所以...

Sharding-SphereSharding-JDBC 最早是当当网内部使用的一款分库分表框架，到2017年的时候才开始对外开源，这几年在大量社区贡献者的不断迭代下，功能也逐渐完善，现已更名为 ShardingSphere，2020年4⽉16⽇正式成为 Apache 软件基⾦会的顶级项⽬。随着版本的不断更迭 ShardingSphere 的核心功能也变得多元化起来。如图7-1，ShardingSphere生态包含三款开源分布式数据库中间件解决方案，Sharding-JDBC、Sharding-Prox