-
复制解决的基本问题
让一台服务器的数据让其他服务器保持同步，一台主库的数据可以同步到多台备库上，悲苦本身也可以被配置成另外一台服务器的主库。
MySQL支持两种复制方式：基于行的复制和基于语句的复制（逻辑复制）。这两种都是在主库上记录二进制日志，在备库重放日志的方式来实现异步的数据复制， 这说明同一时间主备库存在不一致，并且无法保证主备之间的延迟。
-
常见的复制用途
数据分布：MySQL通常复制不会造成很大的贷款压力，但基于行的复制会比基于语句的复制带宽压力大， 可以随意停止或开始复制，并在不同的地理位置来分布数据备份，例如不同的数据中心， 即使在不稳定的网络环境下，远程复制也可以工作，单位了低复制延迟，最好有一个稳定的低延迟连接。
负载均衡：将读操作分布到多个服务器上，实现对读密集型应用的优化
备份：对备份来说，复制是一项很有意义的技术补充，但复制既不是备份也不能取代备份。
高可用性和故障切换：帮助应用程序避免MySQL单点失败，一个包含复制的设计良好的故障切换系统能够显著地缩短宕机时间
MySQL升级测试：使用一个更高版本的MySQL作为备库，保证在升级全部实例之前。查询能够在备库按照预期执行。
-
复制步骤
主库把数据更改记录到二进制日志中
在提交失误完成数据更新前，主库将数据更新的时间记录到二进制日志中，按照事务提交的顺序 而非每条语句的执行顺序来记录二进制日志，在记录之后，主库会告诉存储引擎可以提交事物了。
备库将主库上的日志复制到自己的中继日志中
备库读取中继日志中的时间，将其重放到备库数据之上
-
基于语句的复制
主库会记录那些造成数据更改的查询，当悲苦读取并重放这些事件时，实际上这只是把主库上执行过的SQL在执行一遍
优势：实现简单，二进制日志里面的时间更加紧凑，不会使用太多带宽
劣势：更新必须串行，需要更多的锁，不是所有的引擎都支持这种复制模式，存在一些无法被正确复制的SQL， 存储过程和触发器在使用基于语句的复制模式时也可能存在问题
基于行的复制
将实际数据记录在二进制日志中，可以正确复制每一行，一些语句可以被更有效的复制
-
一主多备结构
为不同的角色使用不同的备库比如 添加不同的所以或使用不同的存储引擎
把一台备库当做代用的主库，除了复制没有其他数据传输
将一台备库放到远程数据中心，用作灾难恢复
延迟一个或多个备库，以备灾难恢复
使用一个备库作为备份、培训、开发、或者测试使用服务器
-
主-被动模式服务器对称设置
确保两台服务器上有相同的数据
启用二进制日志，选择唯一的服务器ID，并创建复制账号
启用备库更新的日志记录
把被动服务器配置成只读，防止可能与主动服务器上的更新产生冲突
启动每个服务器的MySQL实例
将每个主库设置为对方的备库，使用新建的二进制日志开始工作
主动服务器上更新时：更新记录到二进制日志中，通过复制传递给被动服务器的中继日志中 被动服务器执行查询并将其记录到自己的二进制日志中，由于事件的服务器ID与主动服务器的 相同，因此主动服务器忽略这些事件。
这种类似于创建一个热备份，但是可以使用这个备份来提高性能，比如执行读操作、备份、离线 维护升级等。但是不会获得比单台服务器更好的写性能。
-
拥有备库的主-主结构
为每一个主库增加一个备库，增加了冗余，对于不同地理位置的复制拓扑，能够消除站点但电视系哦啊的问题 可以将读查询分配到备库上
主库失效时，用备库来代替主库是可行的，也可以把备库只想一个不同的主库，但需要考虑增加的复杂度
-
环形复制拓扑
每一个服务器都是他之前服务器的备库，是他之后服务器的主库
-
主库 分发主库 备库
分发主库实际上也是一个备库，他的目的是提取和提供主库的二进制日志 多个备库连接到分发主库，原来的主库摆脱了负担，为了避免在分发主库上做实际的查询， 可以将他的表修改为blackhole存储引擎
可以使用分发主库实现对二进制日志时间执行过滤和重写规则，这个比在每个备库上重复进行日志记录、 重写和过滤效率高得多
在分发主库上使用blackhole表，可以支持更多的备库，虽然会在分发主库上执行查询， 但其代价非常小，因为blackhole的表里面没有任何数据，blackhole表的缺点是存在bug， 在某些情况下会忘记将自增的id写入二进制日志
使用分发主库无法使用一个备库来代替主库，因为分发主库的存在，导致各个备库与原始主库的二进制日志坐标已经不相同
-
日志服务器
mysqlbinlog：用来记录mysql内部增删改查等对数据库有更新的内容的记录，对数据库的查询select或show等不会被binlog记录，主要用于数据库的主从复制以及增量恢复
复制作为应用二进制日志的方法已经被大量的用户所测试，能够证明是可行的的，mysqlbinlog可能无法正确生成二进制日志中的数据更新
复制的速度更快，因为无需将语句从日志导出来并传送给mysql
很容易观察到复制过程
方便处理错误，例如可以跳过执行失败的语句
方便过滤复制事件
有时候mysqlbinlog会因为日志记录格式更改无法读取二进制日志
-
缓存
应用层以下的缓存：MySQL服务器有自己的内部缓存，也可以构建自己的缓存和汇总表，缓存表比许多应用层缓存更加持久，在服务器重启之后他们还存在
应用层缓存：在同一台机器的内存中缓存数据，或者通过网络存在另一台机器的内存中， 应用层缓存可以节省获取数据以及基于这些数据进行计算。但是缓存命中率低，并且可能使用更多的内存。
应用缓存之本地缓存：小，只在进程处理请求期间存在于进程内存中。可以避免对某些资源的重复请求
应用缓存之本地共享内存缓存：中等大小，快速，难以在多台机器间同步，对小型的半静态位数据比较合适 ，但是访问非常快，通常比任何远程缓存访问都快
应用缓存之分布式内存缓存：比本地共享内存缓存大得多，增长容易，缓存中创建的数据的每一个比特都只有一个副本，不会浪费内存，也不会因为缓存创建的数据存在不同的地方而引入一致性问题。 非常适合存储共享对象，但是演示高，最有效的方法是批量进行多个获取操作，还要考虑怎么增加更多的节点， 以及某个节点崩溃了怎么处理，应用程序必须决定在节点间怎么分布或充分不缓存对象
应用缓存之磁盘缓存：最好是持久性对象，很难全部存进内存的对象或者金泰内容
-
缓存控制策略
问题：重复数据，有多而地方需要更新数据，所以要避免督导脏数据
TTL（time to live 存活时间）：缓存对象存储是设置一个过期时间，可以通过清理进程在未达到过期时间后删除对象， 或者留到下次访问时再清理，对于数据很少变更或没有新数据的情况，这是最好的失效策略。
显示失效：如果不能接受脏数据，那么在更新原始数据时同时使缓存失效
写——失效：标记缓存数据已经过期（是否清理缓存数据是可选的）。
写——更新：更新数据时替换掉缓存项
读时失效：采用对象版本控制
缓存对象分层：分层缓存对象对检索、失效和内存利用都有帮助，相对于只缓存对象，也可以缓存对象的ID、对象的ID组等需要一起检索的数据
预生成内容：在后台预先请求一些页面，并将结果存为静态页面。
作为基础组件的缓存
使用handlerSocket 和memcached：handlerSocketto 刚刚一个简单的协议访问innodb handler 绕过上层的服务器层，通过网络直接连接innodb引擎，通过memcached协议访问innoDB
-
-
Java高级架构 ∣干货|交流
