如果经常和各种API打交道，那curl命令能让你更快的使用这些API。

如果有写过项目的经历，就免不了将代码上传到服务器上，安装依赖，然后输入启动命令的步骤。但是有的项目往往需要经常性的改动，如果还是照着上面的方式进行部署的话。先不说这样操作的效率，操作个几次就想罢工了。并且上面这样操作的往往容易误操作。而 Github Actions 正是该问题的良药。

集群是一组相互独立的、通过高速网络互联的计算机，它们构成了一个组，并以单一系统的模式加以管理。

虽然Redis单机部署起来比较简单，但是但是可靠性低，且不能很好利用CPU多核处理能力，而且在生产环境中，为了保证高可用的状态，单机运行一般是不可行的，同时为了保证数据的读写分离，降低Redis节点的压力，先来看一看Redis的主从复制。

什么是CAP定理​

在分布式系统中的三个条件

一致性：分布式环境下多个节点的数据是否强一致 可用性：分布式服务能一直保证可用状态。当用户发出一个请求后，服务能在有限时间内返回结果 分区容错性：特指对网络分区的容错性

对于共享数据系统，最多只能同时拥有CAP其中的两个，没法三者兼顾。

任两者的组合都有其适用场景 真实系统应当是ACID与BASE的混合体 不同类型的业务可以也应当区别对待 其中，分区容错性又是不可或缺的。

说一个很常见的场景吧，我们在新闻网站、视频网站浏览新闻视频的时候，它们是怎么给我们推荐那些我们没看过的内容的呢？ 可能你会想到：服务器端储存每个用户的观看记录，在去除掉每个用户已观看的内容，但是这种方法会给服务器端很大的压力，当用户量特别大的时候，每个人看过的内容又很多的时候，效率会大大降低，甚至拖垮服务。 如果每个用户的观看内容是存到了关系型数据库，那每次查询的时候都要顺便判断是否有重复观看的数据，说实话，关系型数据库不适合这种场景。 再假如，把观看数据存到了缓存中，但是这些数据是不会消失的，会随着时间的推移而变得越来越多，时间长了缓存也一样撑不住。 这个时候就需要专业的工具去解决这种场景，我们的布隆过滤器就可以登场了！