Laravel 官方提供 Homestead 和 Valet 作为本地开发环境，但 Docker 相比虚拟机占用体积更小、启动更快，是更好的选择。

计算机中有很多概念和思想看上去很抽象，但在生活中都可以找到对应的场景。当把计算机中的概念和生活联系起来，会发现解决问题的思路都很相似。

2018 年初写过一篇一致性哈希的简短介绍（consistent-hashing-analysis.md），但实际工程里仅靠"环 + 顺时针找节点"是远远不够的——会遇到数据倾斜、扩容迁移量、节点权重、热点等真实问题。本文深入剖析一致性哈希在工程落地中的取舍。

想象一个简单的场景：你的缓存集群有 3 台 Redis，10 万个商品 key 均匀分布。突然业务高峰来了，扩到 5 台——几乎所有 key 都需要重新映射，缓存命中率瞬间掉到零，DB 直接被打挂。

这就是一致性哈希要解决的问题。

内存是易失的。一台物理机的内存条拔掉，断电后所有数据归零；但 Redis 的定位不仅是缓存——当它用作计数器、分布式锁、限流器、排行榜的时候，每一条丢失的数据都可能引发线上事故。

持久化本质上是在"性能"与"数据安全"之间做工程取舍。Redis 提供 RDB（快照）和 AOF（追加日志）两种主流方案，外加 Redis 4.0 引入的混合模式。下面从原理到配置、从场景到踩坑，完整拆解。

现在的应用系统中，大部分密码存储都是采用 md5 加密后存储，常用的登录基本流程如下：

1. 前端 web 页面用户输入账号、密码，点击登录
2. 请求提交之前，web 端首先通过客户端脚本对密码原文进行 md5 加密
3. 提交账号、md5 之后的密码
4. 后端验证账号与密码是否与数据库中的一致

这种流程看似安全，但实际上存在重放攻击风险！

Supervisor 是一个 Python 写的进程管理工具，有时一个进程需要在后台运行，并且意外挂掉后能够自动重启，就需要这么一管理进程的工具。在 Laravel 开发中，也经常使用到队列监听，可以配合 Supervisor 来管理 Laravel 队列进程。

在团队开发中，经常会遇到多个需求同时需要测试的情况。假设只有一个测试服务器，如何让多个开发人员同时测试不同的 git 分支？

一个解决方案是：基于 User-Agent 进行分流。

以下摘自《如何阅读一本书》第二十一章。

我们已经完成了在本书一开始时就提出的内容大要。我们已经说明清楚，良好的阅读基础在于主动的阅读。

所谓主动的阅读，也就是能提出问题来。我们也指出在阅读任何一本书时该提出什么样的问题，以及不同种类的书必须怎样以不同的方式回答这些问题。

我们也区分并讨论了阅读的四种层次，并说明这四个层次是累积渐进的，前面较低层次的内容包含在后面较高层次的阅读里。

2016 年最热的技术话题之一是"协程"。Go 1.7 进一步优化了 goroutine 调度，Lua、Erlang 的协程模型在游戏和电信行业早已成熟。但到底什么是协程？它和线程的区别在哪？——这三个概念必须从操作系统的视角区分清楚，否则永远在"哪个性能更好"上打转。

这篇文章回到最基础的层次：进程、线程、协程在 Linux 内核和 CPU 眼里到底是什么样的东西。

线上服务响应慢了，你第一反应是什么？看应用日志？重启？扩容？这些都不是诊断——是赌博。

性能问题的定位需要一套先全局后局部、先假设后验证的工程方法。Brendan Gregg 在 ACM Queue（2012）和 Systems Performance（2013，Prentice Hall）里总结的 USE 方法（Utilization, Saturation, Errors）是入门最快的框架：对每个资源，先查利用率、查饱和度、查错误。

这篇文章用一台典型的 Linux 服务器（4 核 8GB，跑 Nginx + MySQL + 应用进程）走一遍 USE 流程，掌握 top、vmstat、iostat、mpstat、pidstat、free、strace 的基础读法。

Laravel 的路由功能很强大，路由规则默认都定义在 routes.php 文件中，但是随着项目越来越大，我们需要的定义的规则越来越多，如果几百上千个路由都定义在一个文件中，如何去维护？如果不同的人都在同一个文件定义路由，这就造成了冲突，因此我们有必要将 routes.php 文件分割成多个文件，可以按照功能模块来划分。

鸟哥在博客中说，提高PHP 7性能的几个tips，第一条就是开启OPcache：

记得启用Zend OPcache, 因为PHP7即使不启用Opcache速度也比PHP-5.6启用了Opcache快

Laravel是一个功能强大的框架，组件很多，代码也很庞大，它的易用方便是牺牲了性能的，即便如此它仍然是一个优秀的框架，但在正式环境下要做好优化提升网站的打开速度。

你执行 SELECT * FROM users WHERE id = 1; 时，MySQL 真的去磁盘读数据了吗？多半没有。一次随机磁盘 I/O 大约 10ms，而一次内存访问大约 100ns——差距 10 万倍。这就是为什么 InnoDB 把"把数据搬到内存"这件事做成了一个独立子系统：Buffer Pool。

这篇文章以 MySQL 5.7（InnoDB 1.1.x）为基线，从一个具体查询出发，拆解 Buffer Pool 的内部结构、LRU 淘汰策略、刷脏机制和常见调优陷阱。

这是最早期的 SSR 方式之一——服务端在返回 HTML 前完成页面组装，客户端直接拿到完整页面，而非空壳再客户端渲染。

相信很多人在浏览网页时都遇到过这样的情况：本地在开发环境运行正常的页面，部署到测试环境后却发现部分内容缺失。比如导航栏、页脚、公用组件等内容本地看不到。

如果你遇到这样的情况，先检查一下页面源码中是否有类似这样的代码：

<!--#include virtual="/new/ssi/script.html"-->

这就对了——这就是 SSI（Server Side Include）在起作用。本地没有配置 SSI，所以包含的内容没有渲染出来。