There are only two hard things in Computer Science: cache invalidation and naming things.
计算机科学中有两件难事：缓存失效和命名
– Phil Karlton

From Martin Fowler : TwoHardThings

缓存系统一定程度上极大提升系统并发能力，但同样也增加额外技术考虑因素，下面针对缓存系统设计与使用中面临的常见问题展开。

• 缓存应用的典型场景
• 缓存雪崩
• 缓存穿透
• 缓存更新与数据一致性

事务隔离是分布式系统对一致性保证的重要机制，是保证ACID的重要基础设施。MySQL InnoDB事务隔离级别官方说明中对MySQL的事务隔离机制有详细介绍。

结合示例，本文对事务隔离级别相关术语进行解析。

Redis的maxmemory支持的内存淘汰机制使得其成为一种有效的缓存方案，成为memcached的有效替代方案。

当内存达到maxmemory后，Redis会按照maxmemory-policy启动淘汰策略。

团队内分享PHP7源码，重读代码过程中发现其中不少优秀设计之处，整理一篇其源码中的优雅设计。

现代PHP发展过程中，最初原始的文件拷贝、代码Ctrl+C/V的分发模式，phpear分发模式，再发展到composer横空出世，现代PHP库依赖管理通过composer解决各类库的版本依赖管理。

下文介绍如何打包发布自己的代码库：

眨眼间，依然18年的四月份了，三月艳阳天已过，春雨也已下过一场了。

先说结论：

• 说明：一切抛开网络拓扑提准确获取用户ip的通用方案都是耍流氓。
• 根据网络拓扑当服务器架构中的设备IP加入可信IP列表，成本：持续维护可信IP区、与拓扑相关、增加防火墙WAF调整可信IP
• 剔除可信IP列表
• 从XFF头部倒序获取首个非可信IP作为客户端真实IP，防伪造XFF、防代理、保正常请求
• Laravel/Nginx-realip均按上述逻辑来处理的

网络拓扑模型

线上服务的表结构调整是业务需求扩展和系统设计拓宽的常见方式，但对线上服务而言，线上库表调整可能对线上服务产生影响。
本文以MySQL 5.6.16-log为例，结合InnoDB引擎特性，给出综合分析，几个核心问题：

1. 线上库修改表结构操作是否会导致锁表、锁行？
2. 线上改表结构可用的方案有哪些？各自成本和适用场景？
3. 5.6+ InnoDB引擎的online DDL特性性能表现如何？

Linux内存管理模式，页式管理适合于大块内存的情形，而对于内核对象级别的较小内存情形下，不足以占用1个页。

在linux内核中会有许多小对象，这些对象构造销毁十分频繁，比如i-node，dentry。这么这些对象如果每次构建的时候就向内存要一个页，而其实际大小可能只有几个字节，这样就非常浪费，为了解决这个问题就引入了一种新的机制来处理在同一页框中如何分配小存储器区。这就是我们要讨论的slab层。在讲述slab前，我想先铺垫一下有关内存页的概念，我们都知道在linux中内存都是以页为单位来进行管理的(通常为4KB)，当内核需要内存就调用如：kmem_getpages这样的接口(底层调用__alloc_pages())。那么内核是如何管理页的分配的，这里linux使用了伙伴算法。slab也是向内核申请一个个页，然后再对这些页框做管理来达到分配小存储区的目的的。

结论：正确分析CentOS7系统可用内存的方式

• CentOS 7.0: 通过free和/proc/meminfo中MemAvailable综合确定，以后者为主
• CentOS 7.2: free中Mem:available~=/proc/meminfo中MemAvailable，二者等价

准确的说，应该是CentOS7在初始版本中free未合理获取系统可用内存数据
在CentOS 7.2版本中已增加Mem:available显示正确的系统空闲内存。