记录－交流－Web开发知识分享
Ejabberd官网上Performance Tuning有一写关于优化的clue，这些参数可以在ejabberdctl.cfg里面修改
erl
昨天搞定了一个十万火急的issue，客户抱怨产品升级后系统会变慢和CPU使用率相当高，客户脾气很大，声称不尽快解决这个问题就退货，弄得我们 R&D压力很大，解决这个issue的任务分给了我，客户是南非的一个公司，由于时差问题，我只好在家远程解决问题，晚上8点半用 gotomeeting远程到客户电脑查看我们的系统，折腾了四个多小时，终于在凌晨时reproduce了这个high CPU，赶紧抓Log，用wireshark抓包，用gcore,gstack,strace和top保存了系统的相关输出。在第2天分析了这些文件后， 找到了产品的bug，代码的作者分配了10K的缓冲区，并想当然认为10K足以够用，当然99%的情况下是够用的，但是在这1%的情况下出现了问题，缓冲 区不幸被写满了，然后程序进入了死循环，导致high CPU。找到了问题了，fix就很容易了，客户的脾气也缓和了，fix很快就可以deliver给客户。反思解决问题的过程，觉得这个分析过程具有可复用 性，值得总结一下。…
<?php
//php socket 客户端编程
// 建立一个socket并连接
//选项 SO_REUSEADDR¦SO_REUSEPORT¦TCP_NODELAY¦SO_RCVTIMEO¦SO_SNDTIMEO
//SO_REUSEPORT 端口重用 linux kernel >3.9
//SO_RCVTIMEO 接收数据超时
//SO_SNDTIMEO发送数据超时
//设置socket选项
//$host = "34.56.33.33";
$host = "192.168.6.156";
$port = "1883";
$timeout = 2; //连接超时/秒
$socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
//连接 超时处理
socket_set_nonblock($socket);
$time = … 所有的TCP/IP参数都位于/proc/sys/net目录下（请注意，对/proc/sys/net目录下内容的修改都是临时的，任何修改在系统重启后都会丢失），例如下面这些重要的参数：…
安装最新版本Emqtt，参照官方文档安装后，执行报错：
Linux error while loading shared libraries libsctp.so.1: cannot open shared object file: No such file or directory
从互联网上找到了一些文章， 解决了我的问题，这里整理贴一下，类似的问题应该都可以参照解决。…
问题起因：
自己开发了一个服务器和客户端，通过短连接的方式来进行通讯，由于过于频繁的创建连接，导致系统连接数量被占用，不能及时释放。看了一下18888，当时吓到了。
现象：
1、外部机器不能正常连接SSH…
一、缘起
一切脱离业务的架构设计与新技术引入都是耍流氓。
引入一个技术之前，首先应该解答的问题是，这个技术解决什么问题。
就像微服务分层架构之前，应该首先回答，为什么要引入微服务，微服务究竟解决什么问题（详见《互联网架构为什么要做微服务？》）。…
一、缘起
如《消息总线消息必达》所述，MQ消息必达，架构上有两个核心设计点：
（1）消息落地
（2）消息超时、重传、确认
再次回顾消息总线核心架构，它由发送端、服务端、固化存储、接收端四大部分组成。
为保证消息的可达性，超时、重传、确认机制可能导致消息总线、或者业务方收到重复的消息，从而对业务产生影响。
举个栗子：
购买会员卡，上游支付系统负责给用户扣款，下游系统负责给用户发卡，通过MQ异步通知。不管是上半场的ACK丢失，导致MQ收到重复的消息，还是下半场ACK丢失，导致购卡系统收到重复的购卡通知，都可能出现，上游扣了一次钱，下游发了多张卡。
消息总线的幂等性设计至关重要，是本文将要讨论的重点。
二、上半场的幂等性设计
MQ消息发送上半场，即上图中的1-3
1，发送端MQ-client将消息发给服务端MQ-server
2，服务端MQ-server将消息落地
3，服务端MQ-server回ACK给发送端MQ-client
如果3丢失，发送端MQ-client超时后会重发消息，可能导致服务端MQ-server收到重复消息。
此时重发是MQ-client发起的，消息的处理是MQ-server，为了避免步骤2落地重复的消息，对每条消息，MQ系统内部必须生成一个inner-msg-id，作为去重和幂等的依据，这个内部消息ID的特性是：
（1）全局唯一
（2）MQ生成，具备业务无关性，对消息发送方和消息接收方屏蔽
有了这个inner-msg-id，就能保证上半场重发，也只有1条消息落到MQ-server的DB中，实现上半场幂等。
三、下半场的幂等性设计
MQ消息发送下半场，即上图中的4-6
4，服务端MQ-server将消息发给接收端MQ-client
5，接收端MQ-client回ACK给服务端
6，服务端MQ-server将落地消息删除
需要强调的是，接收端MQ-client回ACK给服务端MQ-server，是消息消费业务方的主动调用行为，不能由MQ-client自动发起，因为MQ系统不知道消费方什么时候真正消费成功。
如果5丢失，服务端MQ-server超时后会重发消息，可能导致MQ-client收到重复的消息。
此时重发是MQ-server发起的，消息的处理是消息消费业务方，消息重发势必导致业务方重复消费（上例中的一次付款，重复发卡），为了保证业务幂等性，业务消息体中，必须有一个biz-id，作为去重和幂等的依据，这个业务ID的特性是：
（1）对于同一个业务场景，全局唯一
（2）由业务消息发送方生成，业务相关，对MQ透明
php-fpm优化方法
php-fpm存在两种方式，一种是直接开启指定数量的php-fpm进程，不再增加或者减少；
另一种则是开始时开启一定数量的php-fpm进程，当请求量变大时，动态的增加php-fpm进程数到上限，当空闲时自动释放空闲的进程数到一个下限。
这两种不同的执行方式，可以根据服务器的实际需求来进行调整。…
近期评论