关于ngx_http_limit_conn_module、ngx_http_limit_req_module 模块，echo（需要安装第三方模块 ngx_http_echo_module），map（默认安装了ngx_http_map_module），geo（默认安装了ngx_http_geo_module）指令请查看官方文档，这里不再赘述。 有四种情况： 不过CDN限速配置 过CDN限速配置 不用白名单的不过CDN 不用白名单的过CDN 首先说明一个问题： geo里面的IP可以是单个的，也可以是一个网段的，只要符合CIDR标准就行。 map里面的IP必须是当个，因为这里把他看着一个变量。 过CDN的白名单IP只需要客户端IP就行，CND不需要，客户端IP得一行一行写 不过CDN的白名单IP可以写一个网段 关键点limited为空时不走限速。有值的，这里white_ip为1,走限速。 测试方法12345678910111213141516171819202122232425262728可以通过echo模块查看到（这两个都是没有走CDN的）：虚拟主机里echo的配置如下locat ...

概念总结集群配置前需要了解架构，集群分片主要分三种： 客户端分片：这个需要自己开发，对客户端要求严格，集群很难扩容 代理端分片：如codis，对客户端几乎无要求，集群容易扩容 服务端分片：如redis集群，需要智能客户端支持集群协议的，集群容易扩容 Codis3.2集群架构 服务端：codis-fe——codis-dashboard——codis-proxy——codis-group——codis-server 客户端：client——nginx-tcp——codis-proxy cdis-fe可以管理多个codis-dashboard 每个codis-dashboard代表一个产品线，每个codis-dashboard可以管理多个codis-proxy 每个codis-proxy可以管理多个codis-server group 每个codis-server group至少由两个codis-server组成，最少1主1备 由上可知一个大的codis集群可以分多个产品线，客户端连接各个产品线的codis-proxy，业务线之间可以做到物理隔离，比如group1，group2，grou ...

部署环境OpenResty1.12.5 Codis3.2集群（客户端不支持Redis集群协议故选择了Codis集群） Nginx1.12.1反向代理 Iis7源站 依赖的第三方模块123456789echo-nginx-module[https://github.com/openresty/echo-nginx-module](https://github.com/openresty/echo-nginx-module) set-misc-nginx-module [https://github.com/openresty/set-misc-nginx-module](https://github.com/openresty/set-misc-nginx-module) redis-nginx-moduleredis2-nginx-module[https://github.com/openresty/redis2-nginx-module](https://github.com/openresty/redis2-nginx-module) srcach-nginx-module  ...

参考文档http://www.redis.cn/topics/cluster-spec.html 键分布模型键空间被分割为 16384 槽（slot），事实上集群的最大节点数量是 16384 个。（然而建议最大节点数量设置在1000这个数量级上） 所有的主节点都负责 16384 个哈希槽中的一部分。当集群处于稳定状态时，集群中没有在执行重配置（reconfiguration）操作，每个哈希槽都只由一个节点进行处理（不过主节点可以有一个或多个从节点，可以在网络断线或节点失效时替换掉主节点）。 以下是用来把键映射到哈希槽的算法（下一段哈希标签例外就是按照这个规则）： HASH_SLOT = CRC16(key) mod 16384 其中，CRC16的定义如下： 名称：XMODEM（也可以称为 ZMODEM 或 CRC-16/ACORN） 输出长度：16 bit 多项数（poly）：1021（即是 x16 + x12 + x5 + 1 ） 初始化：0000 反射输入字节（Reflect Input byte）：False 反射输入CRC（Reflect Output ...

minminmsn.com 是否受够了各博客平台之间频繁切换，精心设计的语言被无辜替换，辛苦维护的博文偶尔遭到无情的误杀，铺天盖地的广告疯狂的轰炸。烦了！倦了！够了！终于我要出手了，现在给你个配方就可以从零开始创建自己的博客，只需要花点儿银子（平均每月百来元即可小玩一把）就能解决以上所有痛点，在自己的地盘自己做主，随意撒野！、具体主要包含如下几步（欢迎各位疯狂点赞、收藏、转载、打CALL、投币）： 一、域名注册 二、域名备案 三、公安备案 四、证书申请 五、架构设计 效果图 架构图 六、部署配置 Nginx部署 Nginx配置 Docker部署 七、前端设计 模板 布局 八、插件选型 九、原创内容 一、域名注册 选择一个有代表性的域名，比如：minminmsn.com参考：https://buy.cloud.tencent.com/domain?from=console 二、域名备案 个人站点备案，借助平台还是很方便的，大概20工作日左右可完成（根据大陆法所有域名需要备案，否则后果自负）参考：https://console.cloud.tencent ...

参考Redis开发与运维 https://redis.io/ http://www.redis.cn/ https://github.com/antirez/redis https://github.com/sohutv/cachecloud 源起优化之路永无止境，在此之前一做过一些架构优化汇总如下： 1，Redis集群3.0.7升级到3.2.9解决读从节点KEY过期不删除问题，集群有几千万KEY原来经核查3.0.7版本只有主上保存过期时间，所以需要主触发才能删除过期的KEY，默认有主动删除与惰性删除同时工作，但是KEY比较多，写的比删除的KEY，另外读从的话不能触发主动删KEY所以会有KEY没更新问题，升级3.2.X之后解决。 2，发现持久化操作时容易导致超时，后来从节点的持久化关闭，效果良好；后续计划持久化非持久化业务分开，过期时间短的与过期时间长的分开。 2，集群扩容，升级到3.2.9版本后为了均摊QPS扩容了几个节点，后续发现有2个节点内核版本比其他的高但是性能反而表现比其他差，后替换了同版本的内核。 3，Bigkeys扫描发现有几个hashkey元素过大超过几千万，单个K ...

RabbitMQ简介AMQP，即Advanced Message Queuing Protocol，高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然。 AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。 RabbitMQ是一个开源的AMQP实现，服务器端用Erlang语言编写，支持多种客户端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX。用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。 官网的配置 http://www.rabbitmq.com/production-checklist.html http://www.rabbitmq.com/configure.html http://www.rabbitmq.com/memory.html http://www.rabbitmq.com/production-checklist ...

纵观儒释道心，没有哪一个不是强调追随内心、反诸求己的，很多人都已经证明了向外求最终都所获甚少或者连方向都错了，说到底就是要有强大的自信力。遇到领导腿不软，遇到大神心不慌，把他们当哥们，平等的对待一切，其实他们本来就和你一样的，你叫声领导与大神是在夸奖他们呢，他们应该赞美你才对，如果他们悟到了。 有不少人包括我认为要是怎样，如果怎样就好了，事实是过去不可念，未来不可思，这样想只是浪费时间而已。比如在家里你就应该是孩子的榜样，哪怕你混得再差在孩子面前你就是老师，得拿出你的担当，告知孩子一流的人生是怎样的，虽然你不能实现但不代表他不行。 123 - ``` 虽然我偶尔遇到一些偏执狂，总以为自己是对的世界是错的，表面上看我是讨厌的，其实我是佩服的。因为他至少行走的是正道，在没有证明自己是错的前为啥不坚持一下呢。就算证明自己错了，那又有什么关系，改过就是了。 有一条现成的路可走，这是阳明祖师首先提出的，简单讲就是：志存高远，勤学苦练，知错就改，自渡渡他，当然最后一条要求比较高首先要悟者才能自渡，其次要有大热心肠才能渡他。 123 - ``` ...

伊藤穰一 杰夫·豪未来社会的三个定义条件 不对称性 复杂性 不确定性 涌现优于权威（Emer-gence over Authority） 新的事物比过去的权威更重要 接受新事物 拉力优于推力（Pull over Push） 自己有需求而主动获取 不要被动接受 指南针优于地图（Compasses over Maps） 找准方向 风险优于安全（Risk over Safety） 愿意承担风险 违抗优于服从（Disobedience over Compliance） 叛逆和对叛逆宽容 实践优于理论（Practice over Theory） 变化快、节奏快 多样性优于能力（Diversity over Ability） 通才比专才重要 团队多样性比单一化有优势 韧性优于力量（Resilience over Strength） 柔能克刚 系统优于个体（Systems over Objects） 整体大于个体

一、 服务稳定性1． 基本监控基本监控推荐使用Zabbix，开源分布式企业级监控系统，能满足目前我们监控的需求 1234a. 系统监控，包括CPU、内存、磁盘、网络等，能够对系统级别的风险进行报警，目前已经实现并线上运行b. 服务进程及端口监控，能够监控服务异常退出，目前已经实现并线上运行c. 自定义脚本程序模拟接口登陆访问结合Zabbix监控日志文件功能，能够对自定义的错误进行报警，目前已经实现并线上运行d. 以上默认系统监控会自动添加，服务进程端口及自定义监控有需要时添加 2． 日志收集日志收集推荐使用Elastic Stack协议栈，可以满足收集海量日志需求，而且便于后续分析、报表、报警操作 1234a. 日志包括服务正常访问日志及错误日志b. 访问日志可以收集客户端IP、响应时间、HTTP状态码、发送字节、Referer、Agent等，也可以自定义字段c. 错误日志可以收集自定义字段错误字段，例如登陆失败、连接超时、后端无响应等d. 以上需要提前准备好日志及定义好日志字段 3． 指标分析123a. 访问日志指标，例如HTTP状态码统计、响应时间分布、其他字 ...