PHP常用Memached做缓存
为理解决这个问题，下面一步步来分解这个问题：
1、哈希表
首先缓存该当是某种特定形式的工具，而不应该是任意类型的变量。由于须要对这些缓存进行标准化的管理，只管C++措辞供应了运算重载，可以对“=”号的写变量操作进行重新定义，但是现在基本没有人推举去做这样的事。而哈希表刚好适宜缓存这种观点的利用。
所有的哈希表（或者是Map接口），都是把数据的存放，分为key和value两个部分，我们可以把想要缓存的数据，作为value存放到“表”当中，同时我们也可以用key把对应的数据取出来，而“表”工具就代表了缓存。
2、让“表”在多个进程中都存在
其次须要让这个“表”能在多个进程中都存在。如果每个进程中的数据都毫无关联，那问题实在就非常大略，但是如果从A进程把数据写入缓存，然后在B进程把数据读取出来，那么就比较繁芜了。总之“表”要有能把数据在A、B两个进程间同步的能力。因此一样平常会用三种策略：租约清理、租约转发、修正广播。
租约清理租约清理，一样平常是指，我们把存放某个key的缓存的进程，称为持有这个key的数据的“租约”，这个租约要登记到一个所有进程都能访问到的地方，比如是ZooKeeper集群进程。那么在读、写发生的时候，如果本进程没有对应的缓存，就先去查询一下对应的租约，如果被其他进程持有，则关照对方“清理”，所谓“清理”，每每是指删除用来读的数据，回写用来写的数据到数据库等持久扮装备，等清理完成后，在进行正常的读写操作，这些操作可能会重新在新的进程上建立缓存。这种策略在缓存命中率比较高的情形下，性能是最好的，由于一样平常无需查询租约情形，就可以直接操作；但如果缓存命中率低，那么就会涌现缓存反复在不同进程间“移动”，会严重降落系统的处理性能。
租约转发
一样平常把存放某个KEY的缓存的进程，称为持有这个KEY数据的“租约”，同时也要登记到集群的共享数据进程中。和上面租约清理不同的地方在于，如果创造持有租约的进程不是本次操作的进程，就会把全体数据的读、写要求，都通过网络“转发”个持有租约的进程，然后等待他的操作结果返回。这种做法由于每次操作都须要查询租约，以是性能会轻微低一些；但如果缓存命中率不高，这种做法能把缓存的操作分担到多个进程上，而且也无需清理缓存，这比租约清理的策略适应性更好。
修正广播
上面两种策略，都须要掩护一份缓存数据的租约，但是本身对付租约的操作，便是一种比较耗费性能的事情。以是有时候可以采取一些更大略，但可能承受一些不一致性的策略：对付读操作，每个节点的读都建立缓存，每次读都判断是否超过预设的读冷却韶光x，超过则清理缓存从持久化重修；对付写操作，每个节点上都判断是否超过预设的写冷却韶光y，超过则展开清理操作。
清理操作也分两种，如果数据量小就广播修正数据；如果数据量大就广播清理关照回写到持久化中。这样虽然可能会有一定的不一致风险，但是如果数据不是那种哀求太高的，而且缓存命中率又能比较有保障的话（比如根据KEY来进行同等性哈希访问缓存进程），那么真正由于写操作广播不及时，导致数据不一致的情形还是会比较少的。这种策略实现起来非常大略，无需一个中央节点进程掩护数据租约，也无需繁芜的判断逻辑进行同步，只要有广播的能力，加上对付写操作的一些配置，就能实现高效的缓存做事。
以是“修正广播”策略是在大多数须要实时同步，但数据同等性哀求不高的领域最常见的手段。著名的DNS系统的缓存便是靠近这种策略：我们要修正某个域名对应的IP，并不是急速在环球所有的DNS做事器上生效，而是须要一定韶光广播修正给其他做事区。而我们每个DSN做事器，都具备了大量的其他域名的缓存数据。
总结
在高性能的做事器架构中，常用的缓存和分布两种策略，每每是结合到一起利用的。虽然这两种策略，都有无数种不同的表现形式，成为各种各样的技能流派，但是只有清楚的理解这些技能的事理，并且和实际的业务场景结合起来，才能真正的做出知足运用哀求的高性能架构。
后面会分享更多devops和DBA方面内容，感兴趣的朋友可以关注下！
