The problem

Because the session of the online PHP cluster always uses one Memcache service, the service response request often has a large standard deviation, which would not happen in theory for the same request. The final positioning problem is caused by a single Memcache.


Try to simulate multiple ports of memcached with Docker on a single machine in the test environment, and simulate requests with multiple browsers on the client side to test the feasibility of shunting the session-memcached cluster with PHP service configuration.


Docker configures the Memcache cluster

Install Docker and remove the memcached public image (do this yourself).

Start three memcached instances:

Docker run --name my-memcache-20 -- p 11220:11211-d memcached:1.5.16 docker run --name my-memcache-20 -- p 11220:11211-d memcached:1.5.16 docker run --name my-memcache-20 -- p 11220:11211-d Memcached :1.5.16 docker run --name my-memcache-30-p 11230: 11211-d memcached:1.5.16 docker run --name my-memcache-30-p 11230: 11211-d memcached:1.5.16

Run Docker ps to check the startup status:

The PHP session – INI configuration

You need to install the memcached extension first. The bottom layer of PHP will do the automatic distributary drop point for the request with memcached. Looking at the official document of memcached, memcached is distributed by the client, and I always thought that the business layer should do the consistent drop point. The memcached extension for PHP has long encapsulated and implemented this functionality for the business layer, for which we configured three test nodes (11210,11220, and 11230)


Open three SSH terminals and check the data of each port in Memcache to enter Memcache

Telnet 11210


We did a lot of tests, one of them dropped, and the other data would randomly fall on the other two.

This is not the only way to solve this problem. The PHP session handler can be implemented by the client code without having to change the configuration in PHP_INI. The YI2 framework can configure the default component:

        'session' => [
            'class' => 'yii\web\Session',
            'name' => 'newrent-frontend-session',
            'timeout' => 3600 * 24,
            'cookieParams' => [
                'path' => '/',
                'domain' => "",

It can also be implemented with a Redis component


It can be seen that the memcached-session cluster of users from different browsers has been distributed. After the browser client obtains the sessionID, the subsequent requests can be guaranteed to access normally. The performance problem of single session-memcache can be solved by using this scheme.