At the beginning, I was wondering why there were two libraries, and there were official documentation support in php.net. I tried to use memcache before. later I found that memcached supports the setMulti method and is ready to switch to the memcached Library.
(I tried it. In fact, memcache supports multi-value set, but it does not exist in the document. it seems that changelog is supported by MySQL 3.0. This function may not be available in the stable version .)
As for efficiency, it is not clear how big the gap will be.
Here is an article that says that memcached is based on libmemcached and may be better.
Finally, the libmemached-based php extension was released in pecl.
So now there are two memcache clients on pecl. One is memcache developed completely within the PHP framework, and the other is memecached using libmemcached.
I have never seen libmemcached, but theoretically, libmemcached, which is already popular in other languages, should have better functions. However, the program performance (memory and CPU usage) is hard to say. although pecl: memcache is implemented in native mode, libmemcached's pecl: memached only supports the OO interface, while pecl:: memcache uses both OO and non-OO interfaces, dragging it down.
In fact, these are not the most important. Libmemcached has an obvious advantage, that is, with the improvement on the memcached server end, this lib will be followed up immediately. Pecl: memcache may not be able to follow up on time.
Pecl: memcached. it is also very commendable that the flag is not set during the operation. Instead, there is a unified setOption (). This method is worth transferring from pecl: memcache to pecl: memcached. Specific interface can see here: http://cvs.php.net/viewvc.cgi/pecl/memcached/memcached-api.php? View = markup
I mentioned in pecl-dev @ whether it can be made into a driver-based architecture. Like MySQL, you can use mysqlnd or libmysql as the underlying engine. However, I don't really support this architecture for memcached. it is different from MySQL.
Mysqlnd is developed as an engine rather than a new api, so that a large number of applications can use the new engine without modifying database operations. If mysqlnd is used as a new extension, it is difficult to choose if it wants to be compatible with previous programs. So far, there are three official MySQL class sets that use libmysql and have different external interfaces. If mysqlnd is compatible with mysql, it cannot be compatible with mysqli or pdo. Of course, for programs that use their own abstract database classes, this can be achieved by rewriting classes or replacing the driver (php layer. But think about it. even if we use abstract databases, so many database abstract libraries in the world, if we want everyone to use the nd, we need to change the number of databases and the number of drivers.
Memcached is much simpler. Currently, only pecl: memcache is closely related to the official website, and the interfaces are basically based on the memcached protocol, which is almost the same as libmemcache. They can all be seen as different drivers in an abstract class. So although there are two sets of different clients, there is almost no need to make any changes after they are changed. you only need to change the settings in the class initialization, set/get, and so on, unless you use non-OO interfaces.
In addition, mysql is more complex in communication and data acquisition than memcache, and nd can do something that libmysql cannot do. For example, the buffer can be directly stored using HashTable and zval in php; for example, some structures that serve as persistent links can be cached more. (These are just my guesses. I have not read the mysqlnd code)
Memcached manual:
Http://cn.php.net/manual/en/book.memcached.php
Memcache manual:
Http://cn.php.net/manual/en/book.memcache.php
Memcached protocol comparison between Chinese and English