Nginx 没有配置 default_server 的情况下，默认就是会匹配到第一个域名

一般在多网卡的网络访问关系中我们通常根据目标IP地址段来添加静态路由表，在主机系统配置层面这个需求一般都比较简单也不需要使用非常复杂的命令，说实话如果不是因为开发测试中心同事 @谢恒 的乱入启发，我也不会发现还有策略路由这样一种灵活通用的配置方法来实现...

跨机房做高可用是为了防止因整个物理机房失活操作业务不可用的情况。当要做跨机房高可用，难点往往就不是高可用切换了，而是数据同步问题，可以搜索关键词「异地多活设计」。

本书让我比较震惊的内容是和惩罚有关的介绍，此前虽然知道搜索引擎有惩罚机制，但却不知道很多看似可以的地方会被惩罚，如：关键词堆积、过度优化、链向不健康网站、外链上升异常、外链质量过差等。

在运维过程中，有一次后端需要切换，按理说，只需要更改 DNS 解析到新的 IP 就能完成切换，然后发现更改 DNS 解析后，走 Nginx 怎么也访问不了后端，而在 Nginx 机器上直接 curl 后端是没有问题的。

前段时间遇到一个诡异的问题，连接走 NAT 转发会出现偶尔连接不通的情况，后来检查发现，NAT 加 tcp_timestamps 和 tcp_tw_recycle 会造成后端服务器丢包。

前段时间线上环境遇到一个问题，在 POST 数据经过 LVS 的时候，会特别慢，100K 的数据往往超过 5 秒，后来研究发现 LVS 在 Centos6（2.6.29-2.6.39） 下，如果开启 GRO，会大量丢包。

上次写了一篇 什么是消息队列？以后，本来想入门一下Kafka的(装一下环境、看看Kafka一些概念啥的)。后来发现Kafka用到了ZooKeeper，而我又对ZooKeeper不了解，所以想先来学学什么是ZooKeeper，再去看看什么是Kafka。

Cross-Origin Read Blocking (CORB) blocked cross-origin response [链接] with MIME type text/html. See [链接] for more details.

这个问题应该改为 PHP Cookie 跨域问题，因为 PHP 的 Session 是通过 cookie 来定位的，Cookie和Session的联系参考 都9102年了，还问Session和Cookie的区别

首先，倒数第四行$array = json_decode($serialize_str, True);似乎是写错了，应该是$array = json_decode($json_str, true);吧。。然后不知道楼主有没有尝试将json段放在文件前面，将serialize段放在文件后面，这样去执行的话你就会发现似乎是json段执行之后有内存...

location 里面的规则要全部匹配上才算命中 = /juejin 这个是精确匹配，uri都对不上，匹配不成功 ^~ ^/jue$ 这个是模糊匹配，非正则匹配，写个正则在这里匹配不到 然后剩下的正则，都匹配不上 忽然发现题目改了.... 这里再说一下，要全部匹配上才算命中，没有说匹配规...

读写分离和分库对应的是不同层面需求，多主库形成不同的集群，然后集群内部做读写分离是常规的操作。 读写分离对应的需求是集群内部分发请求，讨论的时候一般以节点为单位 分库对应的常规操作是集群间分发请求，讨论的时候一般以集群为单位 所以要进行读写分离，那就...

先看一下 PHP 是不是真的没写 Session，直接看 php.ini 里面的 session.save_path (默认/var/lib/php/session) 的位置是什么，如果 Session 目录啥也没有，检查一下文件夹的权限是否正确。如果用的是 mem,redis，进去看一下有没有对应的 key

这个选错驱动表，大表做了驱动表，是不是 order 表也有一个 groupbuyID 字段，手动选择一下 a 表的 groupbuyID {代码...} 如果还是选错驱动表的话，把 o 表的条件改为 having 中筛选 {代码...} 还有一个办法就是把 left join 改为 STRAIGHT_JOIN，手动选择驱动表 {代...

InnoDB如果进行了大量删除造成了页的空洞，这个空洞是指，一个页本来可以存储 m 条数据，现在只存储了 n 条(n<m)，数据分布变得稀疏。这样造成的结果是: 1 维护索引树的成本变高；2 读取相同的数据量，要加载更多的数据页到内存。所以性能会下降。

给一个方案，用户数据增加一个 step 字段，表示生成过程的整个步骤，每完成一步改一下，然后定时查看数据库里没有完成的数据，然后继续执行，可以保证最终一致性。这样设计的一个要求是，事件触发的处理程序是幂等的，同一个事件，只会触发一次或者说触发多次不会有...

先写 redolog 有一个原因是考虑了主从一致性，如果先写 binlog，在写入 binlog 那一刻，就有可能同步到备节点并执行，后续奔溃恢复删除这个 binlog 后，虽然保证了本节点的两个日志一致，但是这个被删除的 binlog 已经被备节点执行了

InnoDB 的数据页大小往往和系统的数据页大小不一致，有可能 InnoDB 为 16k，系统的为 4k，InnoDB 刷新一个数据页，系统要刷新 4 个，这就意味着在系统宕机的时候有可能只刷新了一半的数据页。