Magent、Memcached 负载均匀和容错

柔情只为你懂 2022-08-14 03:41 116阅读 0赞

**一．背景**

Memcached在实现分布集群部署时， Memcached服务端的之间是没有通讯的，服务端是伪分布式，实现分布式是由客户端实现的，客户端实现了分布式算法把数据保存到不同的Memcached服务端。我们在上一篇有介绍了，当我们客户端进行保存也key为keyValue，Value为dataValue时，Memcached服务端我们做了一个测试验证一下，如图所示：

![Center][]![Center 1][]

**二．问题分析**

memcached对容错不做处理的，也就是说当 Memcached服务端挂掉或者Memcached重启复活，由于Memcached重启后无数据，对高并发的大型系统中，是没办法接受的，我们在集群的情况下，要做到负载均衡和容错，这种情况下，服务器端挂掉，负载就不那么均衡，缓存数据也会丢失，重新对数据库进行操作，加大的系统的性能，数据丢失容错也没做得那么好。

**三．解决**

Magent是一款开源的Memcached代理服务器软件，使用它可以搭建高可用性的集群应用的Memcached服务，备份Memcached数据，尽管Memcached服务挂掉，前端也能获取到数据，客户端先连到Magent代理服务器，然后Magent代理服务器在可以连接多台Memcached服务器，然后可以进行数据的保存和备份数据。这样数据就不会丢失，保存了数据完整性。

**四.实现**

**第一步**： 下载并安装Magent并安装

（1）下载地址[http://memagent.googlecode.com/files/magent-0.5.tar.gz][http_memagent.googlecode.com_files_magent-0.5.tar.gz]

（2）先安装好Memcached服务，这个在上一节已经安装好了

（3）Linux上安装Magent

\#tar zxvf magent-0.5.tar.gz

\#/sbin/ldconfig

\#sed -i "s\#LIBS = -levent\#LIBS = -levent -lm\#g" Makefile

\#make

\#cp magent /usr/bin/magent

在执行make出现的问题，[Magen安装出现的问题][Magen]我们在有介绍怎么解决

**  （4）验证一下，有没有安装正确 **

\#magent  能正常显示帮助信息，就说明安装正确，如图所示：

![Center 2][]

**第二步：设置Magent代理的Memcached的服务和备份的Memcached的服务**

（1）启动三个Memcached进程，分别为：

/opt/bin/memcached -d -m 5 -u root -l 192.168.74.129 -p 12000 -c 256 -P /tmp/memcached.pid

/opt/bin/memcached -d -m 5 -u root -l 192.168.74.130 -p 13000 -c 256 -P /tmp/memcached.pid

/opt/bin/memcached -d -m 5 -u root -l 192.168.74.130 -p 14000 -c 256 -P /tmp2/memcached.pid

（2）启动一个magent进程：

magent -u root -n 51200  \-l 192.168.74.129 -p 11000 -s 192.168.74.130:13000 -s 192.168.74.130:14000 -b 192.168.74.129:12000

-s 为要写入的memcached， \-b 为备份用的memcached，  -n number, set max connections, default is 4096

**第三步：测试Magent**

通过客户端连接到缓存代理服务器，缓存代理服务器连接缓存服务器，缓存代理服务器可以连接多台Memcached服务器可以将每台Memcached服务器进行数据同步，我们测试一下Memcached其中一台挂掉，客户端相同的key还能从缓存服务获取数据，还有测试一下数据保存到代理服务器，对应的Memcached服务器也有数据。

（1）我们客户端连接到代理服务器，然后保存数据，Memcached服务器有保存到对应的数据。

第一步：我们连接的我们代理服务器192.168.74.129：11000，然后保存数据，这里我们直接在Linux服务上模拟，如图所示：

![Center 3][]

我们设置key 为keyValue3  value为dataValue3

**第二步：我们查看写入memcached服务有没有对应的添加**

我们查看是保存在192.168.74.130:13000或者192.168.74.130:14000，如图所示：

![Center 4][]![Center 5][]

这时写入的Memcached服务是在192.168.74.130:13000服务上。

**第三步：这时备份Memcached服务器上应该有对应的数据，如图所示：**

**    ![Center 6][]**

**    我们刚才以192.168.74.129:12000为备份的Memcached服务，这时有保存对应的数据，当写入的emcached服务器挂掉可以从这里恢复数据。**

（2）我们客户端连接到代理服务器，然后对原来的key对应的值进行修改时，Memcached服务器有对应的数据应该也是对应的修改

第一步：replace修改，如图所示：

![Center 7][]

第二步：我们查看一下代理服务器有没有对应的修改

我们客户端连接到代理服务器，如图所示：

![Center 8][]

我们原来key 为keyValue3  value变为为dataValueNew3

第三步：我们查看写入memcached服务有没有对应的修改

如图所示：

![Center 9][]

这时之前写入的memcached服务是在192.168.74.130:13000服务上key 为keyValue3  value变为为dataValueNew3

第三步：这时备份Memcached服务器上应该有对应的数据的修改，如图所示：

![Center 10][]

**（3）这时我们把对应的写人的Memcached服务挂掉时，数据会不会通过原来的key获取对应的值**

我们之前查看keyValue3的值放在192.168.74.130:13000服务端，我们关掉服务，这样假设已经挂掉服务，验证一下，能不能获取数据，就是处理容错。

如图所示：

![Center 11][]

这时我们关掉了192.168.74.130:13000服务端的进程

在代理服务192.168.74.129：11000 get keyValue3还能获取数据

![Center 12][]

（4）重启一下memcached服务是在192.168.74.130:13000服务，验证一下还能不能获取数据？

我们之前查看keyValue3的值放在192.168.74.130:13000服务端，我们已经关掉服务，我们重启一下192.168.74.130:13000服务，在192.168.74.129：11000 代理服务能不能获取数据，我们先重启一下192.168.74.130:13000服务器，如图所示：

![Center 13][]

第一步：先查看192.168.74.130:13000的keyValue3

如图所示：

![Center 14][]

这时  192.168.74.130:13000已经没有保存keyValue3对应的值。因为Memcached这边不做持久化数据

第二步：备份先查看192.168.74.129:12000的keyValue3

如图所示：

![Center 15][]

这时备份里还有存keyValue3对应的值，所以可以从备份Memcached服务恢复数据，起到了容错的作用

我们通过192.168.74.129：11000 代理服务上获取keyValue3对应的值

如图所示：

![Center 16][]

这时192.168.74.130:13000服务重启，通过192.168.74.129：11000 代理服务获取不到keyValue3对应的值。

[Center]: https://img-blog.csdn.net/20141126135214656?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvY29uZ2Nvbmc2OA==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center
[Center 1]: /images/20220810/c9a5d465fe8a4398ad4c311a9f6d9a5a.png
[http_memagent.googlecode.com_files_magent-0.5.tar.gz]: http://memagent.googlecode.com/files/magent-0.5.tar.gz
[Magen]: http://blog.csdn.net/congcong68/article/details/41478637
[Center 2]: /images/20220810/cee9409a781e437ea0e9f16019c3aa5f.png
[Center 3]: /images/20220810/a39552d0169d4ce489598d425a452648.png
[Center 4]: https://img-blog.csdn.net/20141126140411406?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvY29uZ2Nvbmc2OA==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center
[Center 5]: /images/20220810/8796a117a60b4dea9d8e19a1f3a5b88e.png
[Center 6]: /images/20220810/c4a387cd12d247a880358267c45613a6.png
[Center 7]: /images/20220810/0a4e3203f5b847c1a625e5796acdf95f.png
[Center 8]: /images/20220810/9f1d00592b774476b483c21303de5e00.png
[Center 9]: /images/20220810/c53661f02d094f1fa654f602a54925f8.png
[Center 10]: /images/20220810/fe062b0e24b84a06a79c7db6e6e51e0a.png
[Center 11]: /images/20220810/18678f66b2a84985a735a997be06ff0f.png
[Center 12]: /images/20220810/ee2202dfaf2e49b78ca992cee740a754.png
[Center 13]: /images/20220810/c38cd5413c04433e8bc8d861e612091d.png
[Center 14]: /images/20220810/1da635e5ba8a48a4babec4f81e28a3d0.png
[Center 15]: /images/20220810/7d24a95d9b534f5d96c02afcb3eed45d.png
[Center 16]: /images/20220810/90435d5ea6414adca8b9a9ac5d6e08d6.png