linux 下Time_wait过多问题解决
问题起因：
自己开发了一个服务器和客户端，通过短连接的方式来进行通讯，由于过于频繁的创建连接，导致系统连接数量被占用，不能及时释放。看了一下18888，当时吓到了。
现象：
1、外部机器不能正常连接SSH…
到底什么时候该使用MQ？
一、缘起
一切脱离业务的架构设计与新技术引入都是耍流氓。
引入一个技术之前，首先应该解答的问题是，这个技术解决什么问题。
就像微服务分层架构之前，应该首先回答，为什么要引入微服务，微服务究竟解决什么问题（详见《互联网架构为什么要做微服务？》）。…
消息总线真的能保证幂等？
一、缘起
如《消息总线消息必达》所述，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进程，当请求量变大时，动态的增加php-fpm进程数到上限，当空闲时自动释放空闲的进程数到一个下限。
这两种不同的执行方式，可以根据服务器的实际需求来进行调整。…
shell脚本监控系统负载、CPU和内存使用情况
这篇文章主要介绍了shell脚本监控系统负载、CPU和内存使用情况,本文分别给出监控服务器系统负载情况、监控系统cpu使用情况、、监控系统内存情况、监控系统交换分区swap使用情况的脚本,需要的朋友可以参考下…
用 netstat 命令，分析网络连接情况
- // 用jps命令，显示所有JAVA进程。
- # jps
- 18374 DesktopServerLauncher
- 14690 Bootstrap
- 23211 Jps
- //除了jps那行，其余全是JAVA进程。
- // 用netstat命令，显示进程ID和程序名(p)；然后用grep命令找出进程18374；然后用head命令显示前3行。
- # netstat -antp | grep 18374 | head -3
- tcp 0 0 :::54104 :::* LISTEN 18374/java
- tcp 0
速率限制-基于漏桶(Leaky bucket)与令牌桶(Token bucket)算法的流量控制
互联网服务赖以生存的根本是流量, 产品和运营会经常通过各种方式来为应用倒流,比如淘宝的双十一等,如何让系统在处理高并发的同时还是保证自身系统的稳定,通常在最短时间内提高并发的做法就是加机器,但是如果机器不够怎么办?那就需要做业务降级或系统限流,流量控制中用的比较多的两个算法就是漏桶和令牌桶.…
你的MQTT应用具备足够弹性吗？
Introduction
Let’s face it: Despite the best intentions and hard work of engineers, software developers and quality assurance folks, software fails. Although it’s an accepted best practice to test software thoroughly in dedicated test and integration environments, failures that are …
原六种网络应用架构模式
六种网络应用架构模式
六种网络应用架构模式，以socket编程为例讲解。
一、串行化
处理请求的串行化模型。
在串行化架构中，所有的客户端连接是依次进行处理的，因为不涉及并发，多个客户端不会同时接受服务。
串行化架构最大的优势在于它的简单性。没有锁，没有共享状态，处理完一个连接之后才能处理另一个。在资源使用方面亦是如此：一个实例处理一个连接，一个萝卜一个坑，绝不多消耗资源。
串行化架构明显的劣势是不能并发操作。即便是当前连接处于空闲，也不能处理等待的连接。…
原PHP处理json的注意点
PHP处理json的注意点:代码说明：
<?php
$json=json_encode($messagebody,JSON_UNESCAPED_UNICODE);//把数据转换成json格式时要加
JSON_UNESCAPED_UNICODE参数，不要把中文转换成 unicode
$data =file_get_contents('php://input', 'r');
$data=ltrim($data,"\XEF\XBB\XBF");//去bom
$json=json_decode($data,false,512,JSON_BIGINT_AS_STRING); //解析json时，记得加
JSON_BIGINT_AS_STRING参数，把大数字转为字符串，防止传入大的数字而解析不完整。
if (json_last_error() === JSON_ERROR_NONE) { //json格式检查
//没错误可以继续了
} else {
//不是一个json格式，记录错误日志
$mmsg=json_last_error_msg();
error_log('not a json:'.$mmsg."\n".$data."\n",3,'errorjson.log');
}
…
近期评论