今天的文章来晚了，主要是我一觉起来变黄码了，关键是我还不知道，早上 8.20 到了公司楼下(最近不在深圳)，保安要看健康码，当我自信满满的打开粤省事却傻眼了，折腾一早上，闹了个乌龙，绿码总算回来了，真是生活处处有惊喜……
书接上回，闲话不表。
今天来说说 mysql 主从复制数据不一致的问题，通过几个具体的案例，来向小伙伴们展示 binlog 不同 format 之间的区别。
1. 准备工作
以下配置基于 Docker。
我这里有一张简单的图向大伙展示 MySQL 主从的工作方式：
这里，我们准备两台机器：
1.1 主机配置
主机的配置就三个步骤，比较容易：
（1）授权给从机 服务器
GRANT REPLICATION SLAVE . to @ identified FLUSH PRIVILEGES
这里表示配置从机登录用户名为 rep1，密码为 123，并且必须从10.3.50.27 这个地址登录，登录成功之后可以操作任意库中的任意表。其中，如果不需要限制登录地址，可以将 IP 地址更换为一个 %。
注意，在 MySQL8 里边，这块有一些变化。MySQL8 中用户创建和授权需要分开，不能像上面那样一步到位，具体方式如下：
USER `rep1`@`10` IDENTIFIED WITH caching_sha2_password GRANT Replication Slave . TO `rep1`@`10`
（2）修改主库配置文件
开启 binlog ，并设置 server-id ，每次修改配置文件后都要重启 MySQL 服务才会生效
开启 binlog 主要是修改 MySQL 的配置文件 mysqld.cnf，该文件在容器的 /etc/mysql/mysql.conf.d 目录下。
针对该配置文件，我们做如下修改：
mysqld# 这个参数表示启用 binlog 功能，并指定 binlog 的存储目录logbinjavaboy_logbin# 设置 binlog_format 格式binlog_formatSTATEMENT# 设置一个 binlog 文件的最大字节# 设置最大 MBmax_binlog_size# 设置了 binlog 文件的有效期（单位：天）expire_logs_days # binlog 日志只记录指定库的更新（配置主从复制的时候会用到）binlogdodbjavaboy_db# binlog 日志不记录指定库的更新（配置主从复制的时候会用到）#binlogignoredbjavaboy_no_db# 写缓存多少次，刷一次磁盘，默认 表示这个操作由操作系统根据自身负载自行决定多久写一次磁盘# 表示每一条事务提交都会立即写磁盘，n 则表示 n 个事务提交才会写磁盘sync_binlog# 为当前服务取一个唯一的 id（MySQL5 开始需要）serverid
各项配置的含义松哥已经在注视中说明了。截图如下：
如下图：
配置完成后重启 MySQL 服务端：
docker restart mysql33061
（3）查看主服务器当前二进制日志名和偏移量
这个操作的目的是为了在从数据库启动后，从这个点开始进行数据的恢复：
show master status
再看一眼 binlog_format 设置成功没：
可以看到，没问题。
至此，主机配置完成。
1.2 从机配置
从机的配置也比较简单，我们一步一步来看：
（1） 在/etc/my.cnf 添加配置
注意从机这里只需要配置一下 server-id 即可。
注意：如果从机是从主机复制来的，即我们通过复制 CentOS 虚拟机获取了 MySQL 实例 ，此时两个 MySQL 的 uuid 一样(正常安装是不会相同的)，这时需要手动修改，修改位置在 /var/lib/mysql/auto.cnf ，注意随便修改这里几个字符即可，但也不可太过于随意，例如修改了 uuid 的长度。
配置完成后，记得重启从机。
（2）使用命令来配置从机
change master to master_hostmaster_portmaster_usermaster_passwordmaster_log_filemaster_log_pos
这里配置了主机地址、端口以及从机登录主机的用户名和密码，注意最后两个参数要和 master 中的保持一致。
注意，由于 MySQL8 密码插件的问题，这个问题同样会给主从配置带来问题，所以在 MySQL8 配置主从上，上面这行命令需要添加 get_master_public_key=1，完整命令如下：
change master to master_hostmaster_portmaster_usermaster_passwordmaster_log_filemaster_log_posget_master_public_key
（3）启动 slave 进程
start slave
启动之后查看从机状态：
show slave status\G
（4）查看 slave 的状态
主要是下面两项值都要为为 YES，则表示配置正确：
Slave_IO_Running YesSlave_SQL_Running Yes
至此，配置完成，主机创建库，添加数据，从机会自动同步。
如果这两个有一个不为 YES ，表示主从环境搭建失败，此时可以阅读日志，查看出错的原因，再具体问题具体解决。
具体的同步过程如下：
大致就是这样一个流程。
2. 数据不一致问题
接下来我们创建一个 javaboy_db 的数据库，并在里边创建一个 user 表，user 表的定义如下：
`user` `id` AUTO_INCREMENT`uuid` DEFAULT `name` DEFAULT PRIMARY KEY `id` ENGINEInnoDB DEFAULT CHARSETutf8mb4
接下来我们在主机中向 user 表中插入一条记录，如下：
按道理，这条记录会同步到 33062 这台从机上：
大家看到，数据确实同步了，但是 uuid 却不一样。
3. 原因分析
我们知道，MySQL 主从同步最主要的依据就是 binlog，master 将自己的 binlog 发给 slave，slave 重放之后获取和 master 一致的数据。
那我们就来看看 master 生成的 binlog 是啥样子。
我们按照事件的方式来看一下 binlog，命令格式如下：
show binlog events posoffset row_count
这个表示以事件的方式来查看 binlog，这里涉及到几个参数：
查看命令如下(我这里就从 pos 为 154 的位置开始)：
show binlog events
查看结果如下(部分)：
从图中可以看到，记录在 binlog 原文中的日志是：use javaboy_db; insert into user(uuid,name) values(uuid(),’javaboy’)。
这句 SQL 将来同步到 slave 之后，slave 照着执行一下，那必然出现执行结果不一致的问题，因为 uuid() 函数每次执行结果都不一样。
现在小伙伴们看明白问题的原因了吧。
4. 问题解决
问题倒也好解决，上篇文章我们说过，我们可以将 binlog_format 设置为 ROW 来解决这个问题。
具体操作步骤如下。
在主机中，修改 /etc/mysql/mysql.conf.d/mysqld.cnf 配置文件，将 binlog_format 改为 ROW，如下：
修改完成后，重启主机，主机重启之后，会产生新的 binlog 文件，所以我们需要重新查看主机的最新状态并重新配置从机，先来看主机，如下：
以此为依据，让从机重新连接主机，在从机上再进行如下操作：
stop slavechange master to master_hostmaster_portmaster_usermaster_passwordmaster_log_filemaster_log_posstart slave
重新配置完从机之后，我们继续向 user 表插入一条数据，插入完成后，我们再去看从机的数据，发现此时的数据已经是一致的了。
解决这个问题，我们最主要的更改就是修改了 binlog_format 为 ROW，当我们把 binlog_format 改为 ROW 之后，我们来看看此时 binlog 中都记录了啥。
show binlog events
大家看到，在 BEGIN 和 COMMIT 之间，就是我们的数据修改操作。
不过这里看不出啥端倪来，我们借助 mysqlbinlog 工具来看看是否有新的发现。
为了查看 binlog，MySQL 为我们提供了两个官方工具，除了上面的 show binlog events，另一个就是 mysqlbinlog 命令，如下(注意在系统中执行该命令，不是在 MySQL 终端执行该命令)：
mysqlbinlog vv varlibmysqljavaboy_logbin
-vv 表示显示详细信息，这样就会打印出 binlog 中二进制文件的内容。
这里的内容比较多，我们来看几个比较关键的地方：
接下来那两行，大致上瞅一眼，像是 Base64 转码后的内容，大家感兴趣的可以自行解码看看，解码后有一些是乱码的，但是有一些字符串如 uuid 则没有乱码，我们也能大致猜出来这里存储的内容。
接下来我们看下面记录的 SQL，如下：
这就是日志中记录的内容，可以看到，每个字段上具体的值是啥，都写下来了，这样当然就不会发生数据不一致的情况了。
5. 小结
好啦，今天通过一个简单的案例，跟小伙伴们分享了 binlog 两种不同的日志格式，另外还有一中 MIXED 格式现在很少用了，感兴趣的小伙伴可以结合上篇文章的内容，在本文案例的基础上继续测试 MIXED 模式，这里我就不赘述啦！
memcached和redis的区别
medis与Memcached的区别传统MySQL+ Memcached架构遇到的问题 实际MySQL是适合进行海量数据存储的，通过Memcached将热点数据加载到cache，加速访问，很多公司都曾经使用过这样的架构，但随着业务数据量的不断增加，和访问量的持续增长，我们遇到了很多问题： 需要不断进行拆库拆表，Memcached也需不断跟着扩容，扩容和维护工作占据大量开发时间。 与MySQL数据库数据一致性问题。 数据命中率低或down机，大量访问直接穿透到DB，MySQL无法支撑。 4.跨机房cache同步问题。 众多NoSQL百花齐放，如何选择 最近几年，业界不断涌现出很多各种各样的NoSQL产品，那么如何才能正确地使用好这些产品，最大化地发挥其长处，是我们需要深入研究和思考的问题，实际归根结底最重要的是了解这些产品的定位，并且了解到每款产品的tradeoffs，在实际应用中做到扬长避短，总体上这些NoSQL主要用于解决以下几种问题 1.少量数据存储，高速读写访问。 此类产品通过数据全部in-momery 的方式来保证高速访问，同时提供数据落地的功能，实际这正是Redis最主要的适用场景。 2.海量数据存储，分布式系统支持，数据一致性保证，方便的集群节点添加/删除。 3.这方面最具代表性的是dynamo和bigtable 2篇论文所阐述的思路。 前者是一个完全无中心的设计，节点之间通过gossip方式传递集群信息，数据保证最终一致性，后者是一个中心化的方案设计，通过类似一个分布式锁服务来保证强一致性,数据写入先写内存和redo log，然后定期compat归并到磁盘上，将随机写优化为顺序写，提高写入性能。 free，auto-sharding等。 比如目前常见的一些文档数据库都是支持schema-free的，直接存储json格式数据，并且支持auto-sharding等功能，比如mongodb。 面对这些不同类型的NoSQL产品,我们需要根据我们的业务场景选择最合适的产品。 Redis适用场景，如何正确的使用 前面已经分析过，Redis最适合所有数据in-momory的场景，虽然Redis也提供持久化功能，但实际更多的是一个disk-backed的功能，跟传统意义上的持久化有比较大的差别，那么可能大家就会有疑问，似乎Redis更像一个加强版的Memcached，那么何时使用Memcached,何时使用Redis呢?如果简单地比较Redis与Memcached的区别，大多数都会得到以下观点： 1Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。 2Redis支持数据的备份，即master-slave模式的数据备份。 3Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。 抛开这些，可以深入到Redis内部构造去观察更加本质的区别，理解Redis的设计。 在Redis中，并不是所有的数据都一直存储在内存中的。 这是和Memcached相比一个最大的区别。 Redis只会缓存所有的 key的信息，如果Redis发现内存的使用量超过了某一个阀值，将触发swap的操作，Redis根据“swappability = age*log(size_in_memory)”计 算出哪些key对应的value需要swap到磁盘。 然后再将这些key对应的value持久化到磁盘中，同时在内存中清除。 这种特性使得Redis可以 保持超过其机器本身内存大小的数据。 当然，机器本身的内存必须要能够保持所有的key，毕竟这些数据是不会进行swap操作的。 同时由于Redis将内存 中的数据swap到磁盘中的时候，提供服务的主线程和进行swap操作的子线程会共享这部分内存，所以如果更新需要swap的数据，Redis将阻塞这个 操作，直到子线程完成swap操作后才可以进行修改。 使用Redis特有内存模型前后的情况对比： VM off: 300k keys, 4096 bytes values: 1.3G used VM on:300k keys, 4096 bytes values: 73M used VM off: 1 million keys, 256 bytes values: 430.12M used VM on:1 million keys, 256 bytes values: 160.09M used VM on:1 million keys, values as large as you want, still: 160.09M used当 从Redis中读取数据的时候，如果读取的key对应的value不在内存中，那么Redis就需要从swap文件中加载相应数据，然后再返回给请求方。 这里就存在一个I/O线程池的问题。 在默认的情况下，Redis会出现阻塞，即完成所有的swap文件加载后才会相应。 这种策略在客户端的数量较小，进行 批量操作的时候比较合适。 但是如果将Redis应用在一个大型的网站应用程序中，这显然是无法满足大并发的情况的。 所以Redis运行我们设置I/O线程 池的大小，对需要从swap文件中加载相应数据的读取请求进行并发操作，减少阻塞的时间。 如果希望在海量数据的环境中使用好Redis，我相信理解Redis的内存设计和阻塞的情况是不可缺少的。
java架构师主要是干什么的？
想成为java架构师，首先你自身得是一个高级java攻城狮，会使用各种框架并且很熟练，且知晓框架实现的原理。比如，你要知道，jvm虚拟机原理、调优；懂得jvm能让你写出的代码性能更优化；还有池技术：什么对象池、连接池、线程池等等。还有java反射技术，虽然是写框架必备的技术，但有严重的性能问题，替代方案java字节码技术，nio 这说不说无所谓，需要注意的是直接内存的特点，使用场景；java多线程同步异步；java各种集合对象的实现原理，了解这些可以让你在解决问题时选择合适的数据结构，高效的解决问题，比如hashmap的实现原理，甚至许多五年以上经验的人都弄不清楚！还有很多，比如，为什扩容时有性能问题？不弄清楚这些原理，不知道问题根本，你就就写不出高效的代码！还会很傻很天真的认为自己是对的，殊不知是孤芳自赏，自命不凡而已；总而验资，言而总之，越基础的东西越重要！许多工作了很多年的程序猿认为自己会用它们写代码了，其实仅仅是知其实仅仅是知道如何调用api而已，知其然不知其所以然，离会用还差的远。关于技能的提升给一些建议1.提升自己的英语水平，此重要性是不言而喻的，现在很多的新技术中文档少之又少，作为一名架构师总不能去看翻译文吧。2.多看一些沟通方面的数据，流畅的沟通利用你成为一名成功的架构师。3.有机会参加PMP考试并取得证书，拥有项目管理方向的优势就是你作为一名架构师的优势。架构师其实从某种意义上就是一种角色，而不是一种职位。一定要时时刻刻保持空杯心态。一定要有一颗保持饥渴学习和耐得住寂寞的赤子之心。4.我们知道当前的技术节奏非常的快，一定要好好的利用自己的碎片时间去学习，去了解新技术，千万不要让自己技术落伍。5.多锻炼自己在大众环境下的演讲和PTT的能力。6.与不同的技术、编程语言、设计模式和结构等（甚至是它并没有在日常中给予你直接的帮助）打交道。你永远都不知道这些知识是否会在未来派上用场，但是对你绝对是有益无害。7.有机会多做知识分享，因为你一旦分享了知识，你就会对这门技术有深刻的印象，同时也能树立在同事中的良好的技术形象，从而赢得更多的专家影响力而不是职位影响力。规划了几张体系图，可以了解一下。一：工程协作专题二、源码分析专题三、分布式专题四、微服务专题五、性能优化专题六、并发编程专题七、项目实战！java架构师课程体系完整页面架构师常用技术：
数据库的多个结构相同表的合并查询
select a,b,c from table_aunion allselect a,b,c from table_bunion allselect a,b,c from table_c
发表评论