表的设计，表之间的关系

你的业务是设计的是什么表，有哪些表，表之间存在什么关系

同步表数据到redis

mybatis是怎么用的：一个缓存，二级缓存，

mycat数据库中间件

mysql数据库备份

为了安全性，需要对数据库实时备份

为什么需要集群

高可用：避免单点故障

分流：负载均衡；

分流，降低并发压力

分离，提高数据库操作速度，提高并发

分流：提高查询速度

mysql集群要解决的问题

保证节点数据一致性：
节点数据实时同步或最终同步

单点故障实时监控，发生单点故障，保证快速切换节点；

集群节点架构

https://zhuanlan.zhihu.com/p/25960208

一主两从
一主多从
多主多从

半同步复制：可以保证节点数据的一致性

网络分区导致脑裂现象

MHA+多节点集群

分布式难题1 - 脑裂

分布式系统的基本问题是网络隔离（network partitions，亦称为脑裂 - split brain） ，和机器崩溃与否很难分辨，例如：一个节点能发现它与另一节点之间有问题，但它无法分辨出对方是崩溃到不能用了，还是只是网络问题（随后可能能或不能修复的网络问题）。

短暂和永久的失败何以难以分辨？因为判断必须在有限的时间内做出，而总会遇到某个短暂的失败持续得比这个有限时间还长。

还有一种情况，就是一个进程没有了响应（僵了），可能是因为它太忙了，或者CPU抢不到（饥饿），或者在做长时间的垃圾收集。这种情况也很难与脑裂、机器崩溃分辨出来。能用来判断的唯一信号只是【在给定时间内没听到心跳】，这意味着，所有造成延迟或没有心跳的情形互相难以分辨，却要一致地来处理。

当节点崩溃时，我们希望立即从集群里移除这个节点。而当脑裂或进程僵了时，我们希望等上一会以期望这是个能恢复过来的短暂失败，但在某个时点我们必须放弃，并且在集群分区的一部分继续运行而在关闭掉其他部分（所有节点）。另外，在脑裂开时一些功能可能不能用了，因而也就不在乎分区故障是短暂的还是长久的。这两种处理方式是互相冲突的，必须进行一个权衡，在尽快移除崩溃节点和短暂脑裂时过早行动之间。

有一个困难的问题要解决，就是找出脑裂两部分中不能通达的节点。我们必须保证两边能独立地做出判断，并且做出谁继续谁停止的一致决定。

MySQL的异步复制和半同步复制

https://www.jianshu.com/p/d877cbe9f0f0

相关工具

mycat：mysql中间件

mysql cluster：mysql 集群

lvs：
本身MySQL Cluster已经实现了高可用，不过由于SQL节点无法对外部负载均衡，因此我们采用 LVS 来实现这一需求。
LVS采用 VS/DR 的模式，

解决方案1:mysql cluster+lvs+keepalived+lpvsadm

解决方案2:mysql cluster+lvs+heartbeat+Ldirector

原来考虑使用Mysql双主+LVS+keepalived+Ipvsadm,因为系统对数据一致性要求很高，双主复制存在此瓶颈，选择使用:Mysql CLuster +LVS+Heartbeat+Ldirector可很好的解决数据及时同步的问题并结合Heartbeat、Ldirector解决高可用、心跳检测、故障转移、负载均衡的需求

mycat数据库中间件

https://www.jianshu.com/p/f94b10c43d55

很多人都会把中间件认为是读写分离，其实读写分离只是中间件可以提供的一种功能，最主要的功能还是在于他可以 分库分表 ，下面是一个读写分离的示意图：

是分布式存储，

还是每个数据库的数据都是完备的，每个数据库都拥有完整的数据，

https://blog.****.net/wangjun5159/article/details/51568249

mycat分库分表，分布式存储

mycat数据库分片，阿里云教程中心
https://www.aliyun.com/jiaocheng/topic_12546_8.html

mycat传智教程
https://blog.****.net/u014229652/article/details/75221058

mysql+mycat+mybatis+redis

mysql+redis

mysql+memcached

mysql+ehcache

mysql导入表到redis

redis导入表到mysql

mysql to redis

redis to mysql

redis数据库键值设计
https://searchdatabase.techtarget.com.cn/7-20441/

ehcache应用场景：
https://tech.meituan.com/cache_about.html
ehcache直接在jvm虚拟机中缓存，速度快，效率高；但是缓存共享麻烦，集群分布式应用不方便。redis是通过socket访问到缓存服务，效率比ecache低，比数据库要快很多，处理集群和分布式缓存方便，有成熟的方案。如果是单个应用或者对缓存访问要求很高的应用，用ehcache。如果是大型系统，存在缓存共享、分布式部署、缓存内容很大的，建议用redis。补充下：ehcache也有缓存共享方案，不过是通过RMI或者Jgroup多播方式进行广播缓存通知更新，缓存共享复杂，维护不方便；简单的共享可以，但是涉及到缓存恢复，大数据缓存，则不合适。

工作方式不一样，可以理解为ehcache是单机版缓存，redis是服务器版的缓存。

作者：知乎用户
链接：https://www.zhihu.com/question/24504292/answer/86908460
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

三级缓存：
https://www.jianshu.com/p/3a5359dce695
redis负责集群
ehcache单机版缓存；
如何更好实现 nginx + redis + ehcache 多级缓存架构，结合lua ，三级缓存架构