Tedis设计
Tedis将结构解耦，用户可以方便的使用其中的全部或部分功能，并能够灵活的扩展自己的需求。
- Tedis-Common:公共依赖基础包，提供了所有的接口和一些工具类。
- Tedis-Atomic:针对单redis实例的byte操作入口。可单独使用。
- Tedis-Group:对Atomic层的封装，提供针对集群的byte接口和object接口操作入口，屏蔽了下层访问细节。
- Tedis-Replicator:依赖Tedis实现的Mysql binlog复制，将Mysql和Redis结合使用的时候会用到。这里还会继续扩展出越来越多的依赖Tedis实现的通用功能的封装。
Redis的命令非常的多，因此Tedis将API进行分类，以方便使用。
- TedisManager Tedis的总的入口，包括针对key的一些列方法以及获取下面其他接口的入口
- ValueCommands 操作普通key-value入口
- AtomicCommands 计数操作入口
- ListCommands List操作入口
- HashCommands Hash操作入口
- SetCommands Set操作入口
- ZSetCommands 排序Set操作入口
我们认为Redis本身的Master-Slave方式并没有解决单点问题，如果Master挂掉，就算可以很快自动切换到Slave也会有短暂的不可用（切换的过程需要时间），而且自动切换也并不是一个容易的活。因此Tedis采用了更加简单的Master-Master结构。
Tedis采用了简单的多写随机读的方式来做高可用保证。既每个写请求会同时在部署的多个Redis实例执行，而每个读请求会根据权重配置随机的在其中一个Redis实例执行，当某个Redis实例出现故障，Tedis会自动检测并把该实例从可用列表中去除，直到该实例恢复Tedis自动将其重新加入可用列表。Tedis目前使用重试机制来保证多个Redis实例间的数据一致性。更优秀的写容灾方案正在讨论中。
在我们的使用过程中，我们发现使用Apache Common Pool来做线程池处理Redis命令效率比较低下，导致Redis的瓶颈在Tedis客户端。于是我们采用了将所有请求串行化，同时实现自己的固定大小的线程池来处理命令。配置合理大小的线程数量可达到Redis理想的性能表现。
Tedis的所有配置都采用Diamond或者Zookeeper等方式实现动态化，既可用动态的改变配置来满足业务需求的变化，比如增加或者变更Redis机器，修改每个机器的权重等。
在互联网大多数应用都是写少读多，而Mysql也是广泛使用，同时Nosql刚刚兴起，大家还是比较乐意将数据放到更加稳定的Mysql，Redis本身也不可能放很多数据，我们只是需要将最近需要的数据放到Redis中。于是，将Mysql和Redis结合起来使用符合当下的形式。 Tedis-replicator可以帮助你实现将Mysql和Redis结合使用，你的应用照常将数据写入Mysql中，Tedis-replicator可以帮助你按照指定的业务逻辑将Mysql的数据实时的同步到Redis，前端应用既可以直接访问Redis实现前台展现。