为了保障数据安全，MySQL 在 5.7 版本就支持了 InnoDB 表空间加密，之前写了一篇月报介绍过，参考InnoDB 表空间加密。文章开头也提到过，MariaDB 除了对表空间加密，也可以对 redo log 和 binlog 加密，本质上 redo log 和 binlog 中也保存着明文的数据，如果文件被拖走数据也有丢失的风险，因此在 MySQL 8.0 中也支持两种日志的加密，本文介绍 Binlog 的加密方式，建议先了解一下表空间加密，更容易理解。

InnoDB 表空间加密是在引擎内部数据页级别的加密手段，在数据页写入文件系统时加密，从文件读到内存中时解密，目前广泛使用的是 YaSSL/OpenSSL 提供的 AES 加密算法，加密前后数据页大小不变，因此也称为透明加密。表空间加密相对于文件系统加密更加灵活，用户可以控制加密重要的表，防止被拖库导致的数据丢失。MySQL 官方在 5.7.11 中发布了表空间加密功能，Aliyun RDS 差不多在同时支持了 RDS MySQL 版的表空间加密，通过了“等保三级” 的认证，随后 MariaDB 在 10.1 支持了功能增强版的“表空间加密”，除了表空间，还可以对 Redo log 和 Binlog 进行加密，参考这篇详细介绍。本文将详细介绍官方的实现方式。

InnoDB会将事务执行过程拆分为若干个Mini Transaction（mtr），每个mtr包含一系列如加锁，写数据，写redo，放锁等操作。

Snapshot Isolation对于接触过数据库领域的同学来说，几乎是入门级的知识了。原因有几点：一来，谈到事务的隔离级别，必然会有所谓Read Uncommitted、Read Committed、Repeatable Read、Serializable，以及Snapshot Isolation；二来，主流的数据库，单机如MySQL、MongoDB，分布式如TiDB、OceanBase，几乎都实现了Snapshot Isolation这一隔离级别；三来，且在非形式化的定义中，Snapshot Isolation也很易于理解，易于实现。

但通过最近对Snapshot Isolatino的系统性研究，发现事情并不是这么简单，例如这几个问题：

• Snapshot Isolation中所说的Snapshot指的是什么，需要满足Consistency约束吗？
• SI对时钟系统的必要约束是什么？必须是一个单调递增的中心化时钟吗？
• SI定义写写冲突，是为了解决什么问题？它是一个必要的约束吗？
• 事务隔离和复制一致性是什么关系？能否基于一个非线性一致的复制协议，实现一个SI？

本篇文章将围绕这几个问题，将时间从2019年拉回到1995年那个雷雨交加的夜晚，围观Hal Berenson等人在小木屋里提出的对ANSI SQL isolation level的critique；再跨越历史的长河，纵观诸多学者对Snapshot Isolation的研究，以望寻得对这些问题的解答。

MySQL Online DDL 功能从 5.6 版本开始正式引入，发展到现在的 8.0 版本，经历了多次的调整和完善。本文主要就 Online DDL 的发展过程，以及各版本的区别进行总结。其实早在 MySQL 5.5 版本中就加入了 INPLACE DDL 方式，但是因为实现的问题，依然会阻塞 INSERT、UPDATE、DELETE 操作，这也是 MySQL 早期版本长期被吐槽的原因之一。

在 MySQL 5.6 中，官方开始支持更多的 ALTER TABLE 类型操作来避免数据拷贝，同时支持了在线上 DDL 的过程中不阻塞 DML 操作，真正意义上的实现了 Online DDL。然而并不是所有的 DDL 操作都支持在线操作，后面会附上 MySQL 官方文档对于 DDL 操作的总结。到了 MySQL 5.7，在 5.6 的基础上又增加了一些新的特性，比如：增加了重命名索引支持，支持了数值类型长度的增大和减小，支持了 VARCHAR 类型的在线增大等。但是基本的实现逻辑和限制条件相比 5.6 并没有大的变化。MySQL 8.0 对 DDL 的实现重新进行了设计，其中一个最大的改进是 DDL 操作支持了原子特性。另外，Online DDL 的 ALGORITHM 参数增加了一个新的选项：INSTANT，只需修改数据字典中的元数据，无需拷贝数据也无需重建表，同样也无需加排他 MDL 锁，原表数据也不受影响。整个 DDL 过程几乎是瞬间完成的，也不会阻塞 DML。

本文将结合MySQL分区表功能重点介绍一致性哈希算法以及其他一些哈希算法的特性和在分区表中的使用。

从2019年开始，作为集团FaaS的实践先锋队，大淘宝技术行业团队在FaaS领域摸爬滚打了三年，并在iFashion、天猫运动等多个业务场景落地。

本文主要讲述了测试环境遇到的问题及其对策。

受浏览器同源策略限制，未知跨域脚本执行错误时，抛出的错误信息为 "Script error."，导致开发者无法定位具体错误。为了获取详细错误信息及堆栈，一般解法是给 Script 标签配置 crossorigin 属性，同时对应脚本服务端需配置 Access-Control-Allow-Origin 响应头。

另外还有一些 hack 解法，对浏览器原生 API 做代理，将业务代码放在 Try Catch 作用域中执行，但写好代理方法是不容易的，粗制滥造的代理方法会制造很多隐藏 Bug，并且大量 Try Catch 在一些 JS Engine 中也存在额外性能损耗，为了解决 Script Error 采用此方案得不偿失。

以B端客服工作台为例，以人格特质的设计应用为重点，继续聊一聊如何将设定好的人格特质设计并应用在产品中。

原研哉在对小米的品牌设计升级中融入了东方哲学的思考，认为“科技越是进化，就越接近生命的形态”，并提出了“ALIVE生命感设计”的概念，由此推导出了最适合体现“生命感”要素和性质的理想图形，引发了业界的关注与讨论。“生命感”一词落实在几何图形上确实抽象，但“生命感”的设计观点值得我们深入思考，体现在品牌气质上如此，体现在IP形象的塑造上亦是如此。文章将以B端客服工作台为例，以「人格塑造」为重点，探索产品IP形象的生命感设计。

什么是响应式编程，它是一种编程范式？还是一种设计模式？抑或是其他？响应式系统和响应式编程有什么关系？又比如，响应式编程它适用于什么场景？解决什么问题？

本次的 input 框方案也算解决了困扰前端输入框的一个难题，希望能给大家带来些启发。

现有的低代码平台普遍缺乏面向用户的调试能力，来看看我们如何探索并实践这个课题。

iLogtail的核心定位是可观测数据的采集器，帮助开发者构建统一的数据采集层，助力可观测平台打造各种上层的应用场景。

拍立淘结果页从上线至今，经历了许多年的迭代，由于当初的实现没有那么精细，导致一直存在一些体验上的问题，​本文将一一介绍这些问题的解决方案。