sharding

jredis是redis的java客户端，通过sharde实现负载路由， 一直很好奇jredis的sharde如何实现，翻开jredis源码研究了一番，所谓sharde其实就是一致性hash算法。其实，通过其源码可以看出一致性hash算法实现还是比较简单的。主要实现类是redis.clients.util.Sharded<R, S>，关键的地方添加了注释： public class Sharded<R, S extends ShardInfo<R>> { //S类封装了redis节点的信息 ，如name、权重 public static final int DEFAULT_WEIGHT = 1;//默认权重为1 private TreeMap<Long, S> nodes;//存放虚拟节点 private final Hashing algo;//hash算法 ...... public Sharded(List<S> shards, Hashing algo, Pattern tagPattern) { this.algo = algo; this.tagPattern = tagPattern; initialize(shards); } private void initialize(List<S> shards) { nodes = new TreeMap<Long, S>

背景 我们知道，当数据库中的数据量越来越大时，不论是读还是写，压力都会变得越来越大。采用MySQL Replication多mater多salve方案，在上层做负载均衡，虽然能够一定程度上缓解压力。但是当一张表中的数据变得非常庞大时，压力还是非常大的。试想，如果一张表中的数据量达到了千万甚至上亿级别的时候，不管是建索引，优化缓存等，都会面临巨大的性能压力。 定义 数据sharding,也称作数据切分，或分区。是通过某种条件，把同一个数据库中的数据分散到多个数据库或者多台机器上，以减小单台机器压力。 分类 数据分区根据切分规则，可以分为两类： 1.垂直切分 数据的垂直切分，也可以称之为 纵向切分。将数据库想象成为由很多个一大块一大块的“数据块”(表)组成，我们垂直的将这些“数据块”切开，然后将他们分散到多台数据库主机上面。这样的切分方法就是一个垂直（纵向）的数据切分。以表为单位，把不同的表分散到不同的数据库或者主机上。规则简单，实施方便，适合业务之间耦合度低的系统。 垂直切分的优点： （1） 数据库的拆分简单明了，拆分规则明确； （2）应用程序模块清晰明确，整合容易； （3）数据维护方便易行，容易定位； 垂直切分的缺点： （1）部分表关联无法在数据库级别完成，需要在程序中完成； （2）对于访问极其频繁且数据量大的表仍然存在性能瓶颈，不一定能满足要求； （3）业务处理相对更为复杂；

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> [TOC] ##引述 前段时间项目需要，一直在研究mysql sharding，看了一些这方面的资料，也亲自实验测试了一些数据。在此，做个概括的笔记，方便以后回顾知识，其实大多是借鉴网络上各位前辈的，然后抱着学习态度去实践，积累属于自己的东西。 ##拆分策略选择 其实拆分很灵活，有的是 垂直切分 ，将一个库拆成两个或多个，将有相关联的表放在一个库里。有的是 水平切分 将数据量大的表按照一定逻辑进行拆分。个人感觉垂直切分的相对来说缓解了IO的瓶颈，而水平切分，目的是减轻了单个表或某些表读写的压力。 我们项目根据个人需求，采用的水平切分，没有去分库。之后要看看需要采用何种的切分了。 了解到的有： 分表、分区、MERGE引擎分表。 ###MERGE引擎分表 ####简介 先介绍merge表，此方法 只 适用于MyISAM。我数据库的表都是采用InnoDB引擎的，所以首先就被pass了，但是还是在这里简单介绍下吧。 mysql 5.1 手册里的说的 An alternative to a MERGE table is a partitioned table, which stores partitions of a single table in separate files. Partitioning enables