背景

前段时间，公司某业务在高并发下，单机单个redis实例中，有个大字符串的get操作总是很慢。查看slowlog并无慢日志记录。

原因

通过咨询掌阅@老钱，得到了以下答复

redis的网络读写和逻辑处理都是单个线程处理的，slowlog只是衡量逻辑处理的时间并不包括接受指令和发送响应的时间。字符串的get操作逻辑非常快，所以slowlog没有任何信息。但是网络读写就慢了，特别是高并发下，内存中有大量待发送的缓冲数据堆积在那里，单线程需要拼命地发送数据，所以才会这样缓慢。

解决方案

当时考虑了两种解决方案：

1. redis集群
2. 将value进行本地缓存

考虑到项目初期的架构及业务代码的改动量，决定选择第二种方式解决，那么由于项目架构采用的是传统的nginx+php-fpm，无法常驻内存，于是决定利用/dev/shm（tmpfs）将这个value缓存到本地内存文件系统中。

既然用到了本地缓存，就要考虑集群下机器的value一致性，所以最终使用redis在每台机器上部署了一个订阅服务，当value发生改变时，更新本地缓存。

效果

从zabbix中可以很明显看到网络传输的峰值下降了非常多，可见这个key在业务高峰期时读取有多频繁。

结论

对于大字符串，偶尔读写不会存在问题，但是在频繁读写就会给redis带来不小的压力。…

外网服务器

首先准备一套可以外网访问的服务器，并且安装nginx ，以centos为例

yum install nginx
service nginx start

编辑nginx的配置文件

vim /etc/nginx/conf.d/default.conf

server {
    listen 8000;
    server_name test.im050.com;
    location / 

布隆过滤器是一种空间利用率高，可以用来对数据进行排重过滤处理的数据结构，具有以下两点特征：

• 判定为不存在的数据一定不存在
• 判定为存在的数据可能存在也可能不存在

存在的数据如果实际上并不存在，称为false positive，那么为什么会有这种现象呢？

布隆过滤器是通过k个hash函数将某个key映射到m个的比特位上。那么某个key的比特位有可能会被其他的一个或多个key占用，即会产生误判为存在的情况，所以这个误判率取决于k(hash函数个数)、m(比特位个数)、n(元素个数)，关于误差率推导，由于我的数学比较不好，还没领悟透彻，可以参考网络上其他文章。

因为比特位非0既1，且多个key共享比特位，也导致了布隆过滤器无法删除已添加的元素，因为删除某个key会影响到其他key。

当然还有一些其他变种的布隆过滤器使得可以删除元素，例如将比特位变成一个计数器，删除元素时只需要将计数器-1即可。…

#include <stdio.h>
#include <hiredis/hiredis.h>
int main()
{
     redisContext *conn  = redisConnect("127.0.0.1",6379);
     if(conn != NULL && conn->err)
     {
         printf("connection error: %s\n",conn->errstr);
         

先附上例子

<?php
class A {
    public $b = null;
    public $str = '';
    public function __construct(B $b)
    {
        $this->str = 

首先通过strace命令跟踪假死进程的系统调用信息

strace -p 16618

执行以上命令后，得到如下结果

poll([{fd=33, events=POLLOUT|POLLWRNORM}], 1, 0) = 0 (Timeout)
poll([{fd=33, events=POLLOUT}], 1, 1000) = 0 

swoole简介

面向生产环境的 PHP 异步网络通信引擎，可以通过该扩展快速创建TCP/UDP服务端、Http服务端、websocket服务端。

Task进程简介

如果没有接触过swoole可以先上swoole官网了解swoole的进程模型

在swoole_server中提供了task的进程，用来异步处理耗时的任务，只需要配置swoole_server时设置task_worker_num即可启用task进程，在worker进程中使用$server->task(array $data)进行任务的投递，但是在任务耗时且量大的情况下会出现任务丢失的现象，所以决定采用第三方来实现队列，来确保数据的完整和可靠性。…

前几天，接到一个需求，需要构建一个简单的直播平台，这也是第一次接触到直播方面的开发任务，带着学习与挑战的精神决定记录下来这次开发的全过程。

经过几番查阅资料，对于如何构建一个直播平台有了一些初步的概念。

1、协议

首先来说说直播的协议，在查阅资料的过程中发现以下三种普遍应用的协议。

1. RTMP(Real Time Messaging Protocol)
2. RTSP(Real Time Streaming Protocol)
3. HLS(HTTP Live Streaming)

关于这三种协议，前二者是基于TCP/UDP进行实时的数据传输，HLS则是采用了…