Posts

Python GIL（Global Interpreter Lock） 全局解释器锁，CPython 实现时引入的概念，为了解决多线程数据完整性和同步问题。GIL 是一个防止解释器多线程并发执行机器码的一个全局互斥锁。其存在主要是因为在代码执行过程中，CPython 的内存管理不是线程安全的。 进程、线程、协程 进程：进程是资源分配的最小单位，每个进程拥有独立的代码区，堆，数据区。 线程：线程是 CPU 调度的最小单位，一个进程至少拥有一个线程，多个线程共享进程的资源。 协程：协程是基于事件循环的单独的子程序，协程可以被中断并在适当的时候重新执行。 MySQL 存储引擎 innodb：支持事务，外键，行级锁，聚蔟索引和辅助索引。 myisam：不支持事务，外键，支持表级锁，不支持聚蔟索引，主键索引和辅助索引结构一样。 查询计划 主要查看 key、extra 等信息，key 表示查询用到的索引，extra 包含多种信息。 using index：查询使用了索引。 using where：MySQL 将在存储引擎检索行后再进行过滤。 using temporary：使用了 join 但是使用了其他表的字段作为查询条件。 using filesort：排序没有走索引。 索引 ACID 原子性：一个事务要么全部提交成功，要么全部失败，不能只执行一部分操作。 一致性：事务前后数据的完整性必须保持一致。 隔离性：多个事务之间相互隔离。 持久性：事务一旦被提交，就会永久保存在磁盘中。 隔离级别 读未提交：可读取其它事务为提交的数据，会产生脏读 读已提交：可读取其它事务已提交的数据，会产生重复读取返回不同结果的情况 可重复读：多次重复读取会得到相同的结果，但是会产生幻读 串行化：对所有 select 强制加共享锁，使之不相互冲突，可能产生大量的超时现象和锁竞争 三大 log binlog 记录 sql 语句，通过追加日志的形式写入，主要使用场景为主从复制与数据恢复。 有 STATMENT，ROW，MIXED 三种格式，STATMENT 记录修改数据的 SQL，减少日志量，某些情况会导致主从数据不一致；ROW 记录变动的数据，可能会产生大量的日志；MIXED 优先使用 STATMENT，STATMENT 不支持的使用 ROW。 redolog 记录事务对哪些数据进行了修改，实现一致性，先写 redolog buffer，再写磁盘文件。 undolog 记录数据的逻辑变化，比如 INSERT 的时候记录一条 DELETE，UPDATE 的时候记录一条相反的 undolog，在发生错误时通过 undolog 回滚到事务之前的状态。 ...

今天突然收到一笔 PayPal 的 20 美元的转账，一开始看到邮件的时候还以为是垃圾邮件之类的，仔细一看没想到是真的。第一次收到开源项目的捐赠，说实话还有点激动。并不是钱的问题，而是自己的开源项目得到肯定，那种成就感与满足感是难以言说的。 本身做开源项目也是自己的兴趣与爱好，编写的也都是自己想要编写的代码，比起业务代码的枯燥，千篇一律，做自己的项目更能让自己灵感勃发，拥有成就感与满足感，甚至是废寝忘食。 作为一个程序员，从开源社区也是获益良多，而我觉得最好的回馈方式就是同样做开源项目，回馈社区。而身边却似乎很少能找到与自己同样想法的人，或为生活，或为利益，本身并不是热爱编程。而真正编程乐趣所在，也只有志同道合的人之间才能相互理解吧。与代码打交道，总是比复杂的任性要简单得多。

项目地址 https://github.com/long2ice/synch mysql2ch mysql2ch 从二月份开始到现在已经接近四个月，项目起初是源于公司的需求，同步 MySQL 的数据到 ClickHouse 进行分析与统计。当时调研了一圈，发现并没有符合需求的项目，只找到一个勉强可用的，于是在该项目之上进行开发与完善。 synch mysql2ch 项目改名为 synch，其主要原因在于 mysql2ch 支持了 postgres 的同步，再取名为 mysql2ch 就有些不合适了，遂改名为 synch，意思是同步到 ClickHouse，其项目目标是同步其它类型的数据库到 ClickHouse 中。 当前架构 设计与实现 最开始的版本非常简陋，只是实现了监听 mysql binlog 然后直接插入到 ClickHouse。在后续的开发与迭代中，逐渐实现了以下功能，以及引入了中间件。 命令行 命令行对于一个独立程序是有必要的。命令行程序可以接受自定义的参数，通过在程序指定不同的参数，可以使用其不同的功能，对于那些需要每次启动都可能会不同的参数，将其放在命令行参数中是有必要的。 配置文件 丰富的配置项可以将程序的自定义配置暴露出来，以满足个性化的运行需求，增强程序的自定义性。 模块分离 该项目分为三个模块，除了源数据库与目标数据库，也就是 ClickHouse 之外，包含生产端、消息队列、消费端。模块的分离是为了解耦，各个模块专注于自身的功能实现以及可靠性。以及借助于消息队列，实现分布式消费。 消息队列 消息队列的引入是为了增加程序的健壮性以及增加生产与消费的性能。通过引入消息队列，将 binlog 先缓冲到消息队列中而不是直接插入到 ClickHouse，避免了当程序崩溃时内存数据的丢失。并且借助于消息队列的 ack 机制，可以保证消息的可靠消费；以及借助消息队列的高吞吐量，将消费者与生产者分离，生产者与消费者之间互不影响，异步工作。 另外一点考虑到 binlog 的有序性，消息队列的选型也是需要考虑的，目前选择了 kafka 和 redis。redis5.0 提供了原生的消息队列并且具有所有消息队列该有的功能，并且消息是有序的，其轻量的特性在并发量不那么大的时候是一个很好的选择；而选择 kafka 是因为其强大的吞吐量，并且单个 topic 的单个分区也是有序的，可以很好的对应需要同步的数据库与数据库表。 redis redis 的引入其一是为了缓存 MySQL 的 binlog，因为 MySQL 的 binlog 是不断在变化的，当程序崩溃或重启时，需要记录当前的 binlog，然后下次启动时需要从上次的位置继续监听；其二是作为消息队列，相比 kafka 而且因为本身既作为缓存组件也作为消息队列，组件依赖较少。 ...

在使用 k8s 的时候，偶然遇到了一个问题，就是死活删不掉 namespace。这个 namespace 处于 Terminating 状态已经十多天，虽然对 k8s 本身并没有什么影响，但是对于我这种强迫症来说很痛苦。 网上也查询了很多种处理方式，大部分都是讲 namespace 以 json 格式导出，然后删除spec部分，再调用 rest 接口，然而我一直都没有成功。 最后不知道在哪里看到一篇文章，直接调用 etcdctl，执行docker exec -it etcd etcdctl del /registry/namespaces/delete-me，因为我的 etcd 是一容器安装的，最终删除成功，治好了强迫症。

夜深，音箱里播放着舒缓的音乐，却怎么也无法让内心平静下来。 屋里又只剩下一个人，门窗紧闭着，有些让人沉闷。窗外似乎下着小雨，又听着车来车往的声音，来去匆匆，也不知目的何处。 好像突然之间就迷茫了。 不知道该做什么，又好像什么都提不起兴趣。反复打开，关闭，鼠标好像漫无目的地胡乱点击，一会儿又打开 github，一会又打开 IDE，又上会儿 v2，然后最终迷失了。 已经好久不曾玩游戏了，总觉得肩上的担子很重，又觉得玩游戏好像很浪费时间，想着还不如做些更有意义的事情，却再也回想不起很久以前玩游戏的心情了。 不知是生活改变了自己，还是自己改变了生活。 总觉得现在做的事情不是自己想做的，却不得不做，多少身不由己，也无从说起。 夜深了，明天终会如期而至。