- 所以这里需要引入一个告警策略，使得告警更加的人性化。这个机制的核心就是4点。 梳理不同的告警级别 制定告警频率以及做好「收敛」（主要是去重、合并数量） 决定不同的告警级别通过什么形式发出通知（短信、手机通知、邮件等） 发给谁（比如，是不是需要“轮转”或者“逐级上报”这样） 所以这里需要引入一个告警策略，使得告警更加的人性化。这个机制的核心就是4点。 梳理不同的告警级别 制定告警频率以及做好「收敛」（主要是去重、合并数量） 决定不同的告警级别通过什么形式发出通知（短信、手机通知、邮件等） 发给谁（比如，是不是需要“轮转”或者“逐级上报”这样）
- 就是你虽然还是排着队“占着坑”，但是人没闲着，低头玩玩手机，时不时的问里面“我的奶茶做好了没？我的奶茶做好了没？”。这个就是「非阻塞」，因为你两次询问之间会间隔一段时间，可以在这个时候做其它的事情。本质上是通过将原本的一个「大同步」拆成多个「小同步」达到「非阻塞」的效果。 就是你虽然还是排着队“占着坑”，但是人没闲着，低头玩玩手机，时不时的问里面“我的奶茶做好了没？我的奶茶做好了没？”。这个就是「非阻塞」，因为你两次询问之间会间隔一段时间，可以在这个时候做其它的事情。本质上是通过将原本的一个「大同步」拆成多个「小同步」达到「非阻塞」的效果。
- 可能你会想，为什么会存在大量的这种db中数据不存在的情况呢？其实，任何依赖外部参数进行查询的地方都可能有这个问题的存在。比如，一个文本输入框，本来是让你输入用户名的，但是手误输入了密码，自然就找不到数据咯。更主要的问题是，会有恶意分子利用这种机制来对你的系统进行攻击，击穿缓存搞垮你的数据库，导致整个系统全面瘫痪。 可能你会想，为什么会存在大量的这种db中数据不存在的情况呢？其实，任何依赖外部参数进行查询的地方都可能有这个问题的存在。比如，一个文本输入框，本来是让你输入用户名的，但是手误输入了密码，自然就找不到数据咯。更主要的问题是，会有恶意分子利用这种机制来对你的系统进行攻击，击穿缓存搞垮你的数据库，导致整个系统全面瘫痪。
- 解决这个问题的方式中有两种和之前我们聊过的Session问题（《做了「负载均衡」就可以随便加机器了吗？》）是类似的。要么是由接收修改的节点通知其它节点变更（通过rpc或者mq皆可），要么借助一致性hash让同一个来源的请求固定落到一个节点上。后者可以让不同节点上的本地缓存数据都不重复，从源头上避免了这个问题。 解决这个问题的方式中有两种和之前我们聊过的Session问题（《做了「负载均衡」就可以随便加机器了吗？》）是类似的。要么是由接收修改的节点通知其它节点变更（通过rpc或者mq皆可），要么借助一致性hash让同一个来源的请求固定落到一个节点上。后者可以让不同节点上的本地缓存数据都不重复，从源头上避免了这个问题。
- 数据库本身自带缓存模块的，否则也不会叫它内存杀手，基本上你给多少内存就能吃多少。数据库缓存是数据库的内部机制，我们这里就不深入下去了。一般都会给出设置缓存空间大小的配置来让你进行干预。最后，其实磁盘本身也有缓存。所以你会发现，为了让数据能够平稳的写到物理磁盘中真的是一波三折，不知道什么时候可以有“快”到不需要程序来考虑缓存的磁盘出现来拯救我们程序员呢。 数据库本身自带缓存模块的，否则也不会叫它内存杀手，基本上你给多少内存就能吃多少。数据库缓存是数据库的内部机制，我们这里就不深入下去了。一般都会给出设置缓存空间大小的配置来让你进行干预。最后，其实磁盘本身也有缓存。所以你会发现，为了让数据能够平稳的写到物理磁盘中真的是一波三折，不知道什么时候可以有“快”到不需要程序来考虑缓存的磁盘出现来拯救我们程序员呢。
- Hash切分：与「范围切分」正好相反，这是一种「离散式」的切分方式。它的优点就是解决了「范围切分」的缺点，新数据被分散到了各个节点中，避免了压力集中在少数节点上。同样，缺点与「范围切分」的优点相反，一旦进行二次扩展，必然会涉及到数据迁移。因为Hash算法是固定的，算法一变，数据分布就变了。 Hash切分：与「范围切分」正好相反，这是一种「离散式」的切分方式。它的优点就是解决了「范围切分」的缺点，新数据被分散到了各个节点中，避免了压力集中在少数节点上。同样，缺点与「范围切分」的优点相反，一旦进行二次扩展，必然会涉及到数据迁移。因为Hash算法是固定的，算法一变，数据分布就变了。
- 顾名思义，微内核架构的关键是内核。所以需要先找到并明确内核是什么？然后将其它部分都视作“可拆卸”的部件。好比我们一个人，大脑就是内核，其它的什么都可以换，换完之后你还是你，但是大脑换了就不是你了。微内核架构整体上由两部分组成：核心系统和插件模块。 顾名思义，微内核架构的关键是内核。所以需要先找到并明确内核是什么？然后将其它部分都视作“可拆卸”的部件。好比我们一个人，大脑就是内核，其它的什么都可以换，换完之后你还是你，但是大脑换了就不是你了。微内核架构整体上由两部分组成：核心系统和插件模块。
- 要更好的做好这个「无状态」化的工作，依赖于你在架构设计或者项目设计中的合理分层。尽量将会话状态相关的处理上浮到最前面的层，因为只有最前面的层才与系统使用者接触，如此一来，其它的下层就可以将「无状态」作为一个普遍性的标准去做。 要更好的做好这个「无状态」化的工作，依赖于你在架构设计或者项目设计中的合理分层。尽量将会话状态相关的处理上浮到最前面的层，因为只有最前面的层才与系统使用者接触，如此一来，其它的下层就可以将「无状态」作为一个普遍性的标准去做。
- 正如之前几篇文章所说，一次跨机器的通信可能会经过DNS 服务，网卡、交换机、路由器、负载均衡等设备，这些设备都不一定是一直稳定的，在数据传输的整个过程中，只要任意一个环节出错，都会导致问题的产生。而在分布式场景中，一个完整的业务又是由多次跨机器通信组成的，所以产生问题的概率成倍数增加。但是，这些问题并不完全代表真正的系统无法处理请求，所以我们应当尽可能的自动消化掉这些异常。 正如之前几篇文章所说，一次跨机器的通信可能会经过DNS 服务，网卡、交换机、路由器、负载均衡等设备，这些设备都不一定是一直稳定的，在数据传输的整个过程中，只要任意一个环节出错，都会导致问题的产生。而在分布式场景中，一个完整的业务又是由多次跨机器通信组成的，所以产生问题的概率成倍数增加。但是，这些问题并不完全代表真正的系统无法处理请求，所以我们应当尽可能的自动消化掉这些异常。
- 每一个上游系统都可以理解为是其下游系统的客户端。然后我们回想一下前面的内容，可能你发现了，前面聊的「限流」都没有提到到底是在客户端做限流还是服务端做，甚至看起来更倾向是建立在服务端的基础上做。但是你知道，在一个分布式系统中，一个服务端本身就可能存在多个副本，并且还会提供给多个客户端调用，甚至其自身也会作为客户端角色。那么，在如此交错复杂的一个环境中，该如何下手做限流呢？我的思路是「一纵一横」 每一个上游系统都可以理解为是其下游系统的客户端。然后我们回想一下前面的内容，可能你发现了，前面聊的「限流」都没有提到到底是在客户端做限流还是服务端做，甚至看起来更倾向是建立在服务端的基础上做。但是你知道，在一个分布式系统中，一个服务端本身就可能存在多个副本，并且还会提供给多个客户端调用，甚至其自身也会作为客户端角色。那么，在如此交错复杂的一个环境中，该如何下手做限流呢？我的思路是「一纵一横」
- 首先，如果所依赖的系统是多副本或者做了分区的，那么要注意其中个别节点的异常并不等于所有节点都存在异常，所以需要区别对待。 其次，熔断往往应作为最后的选择，我们应优先使用一些「降级」或者「限流」方案。因为“部分胜于无”，虽然无法提供完整的服务，但尽可能的降低影响是要持续去努力的。比如，抛弃非核心业务、给出友好提示等等 首先，如果所依赖的系统是多副本或者做了分区的，那么要注意其中个别节点的异常并不等于所有节点都存在异常，所以需要区别对待。 其次，熔断往往应作为最后的选择，我们应优先使用一些「降级」或者「限流」方案。因为“部分胜于无”，虽然无法提供完整的服务，但尽可能的降低影响是要持续去努力的。比如，抛弃非核心业务、给出友好提示等等
- 严格来说「Session保持」本质上是破坏了做「负载均衡」的初衷。举个极端点的场景：一共有10个会话连在了节点A上，并且都是活动中状态。那么这个时候哪怕增加一个节点B上线，只要没有新的会话进来，节点B上的活动连接数永远是0，并没有起到分担压力的作用。 严格来说「Session保持」本质上是破坏了做「负载均衡」的初衷。举个极端点的场景：一共有10个会话连在了节点A上，并且都是活动中状态。那么这个时候哪怕增加一个节点B上线，只要没有新的会话进来，节点B上的活动连接数永远是0，并没有起到分担压力的作用。
- 关于LVS的模式选择，如果在同网段内的话优先使用DR模式进行L2转发，性能最好。否则使用TUN模式进行L3分发。与此同时，在L4、L7的分发上使用Nginx来做，可以发挥其灵活易扩展的特点以及其它的一些额外特性如缓存等，也算是物尽其用。 关于LVS的模式选择，如果在同网段内的话优先使用DR模式进行L2转发，性能最好。否则使用TUN模式进行L3分发。与此同时，在L4、L7的分发上使用Nginx来做，可以发挥其灵活易扩展的特点以及其它的一些额外特性如缓存等，也算是物尽其用。
- 不过，相对的，还可以投机的理解为，只要我能保证系统在你使用它的时候是可用的，那么对外宣传也可以是「高可用」的。这也是在互联网普及之前，很多企业的内部C/S架构的信息系统得以正常使用的原因，比如银行会在非营业时间更新他们的系统，所以对于服务窗口的营业员来说，系统并没有不可用，因为那个时候我不需要用它。 不过，相对的，还可以投机的理解为，只要我能保证系统在你使用它的时候是可用的，那么对外宣传也可以是「高可用」的。这也是在互联网普及之前，很多企业的内部C/S架构的信息系统得以正常使用的原因，比如银行会在非营业时间更新他们的系统，所以对于服务窗口的营业员来说，系统并没有不可用，因为那个时候我不需要用它。
- 「Paxos」算法是一种无领导人（Leaderless）算法，实现比较复杂，所以产生了很多变种来简化它，其中名气最大的应该是「Raft」，2013年才问世。「Raft」算法是一种领导人（Leadership）的算法。由以下2个过程保证达成共识：只会存在一个活着的领导人，领导人负责跟随者的数据同步。如果领导人“失联”了，那么每个跟随者都可成为候选人，最终比较谁的term最新，谁就是新的领导人。 「Paxos」算法是一种无领导人（Leaderless）算法，实现比较复杂，所以产生了很多变种来简化它，其中名气最大的应该是「Raft」，2013年才问世。「Raft」算法是一种领导人（Leadership）的算法。由以下2个过程保证达成共识：只会存在一个活着的领导人，领导人负责跟随者的数据同步。如果领导人“失联”了，那么每个跟随者都可成为候选人，最终比较谁的term最新，谁就是新的领导人。
上滑加载中
推荐直播
-
GaussDB管理平台TPOPS，DBA高效运维的一站式解决方案2024/12/24 周二 16:30-18:00
Leo 华为云数据库DTSE技术布道师
数据库的复杂运维，是否让你感到头疼不已？今天，华为云GaussDB管理平台将彻底来改观！本期直播，我们将深入探索GaussDB管理平台的TPOPS功能，带你感受一键式部署安装的便捷，和智能化运维管理的高效，让复杂的运维、管理变得简单，让简单变得可靠。
回顾中 -
DTT年度收官盛典：华为开发者空间大咖汇，共探云端开发创新2025/01/08 周三 16:30-18:00
Yawei 华为云开发工具和效率首席专家 Edwin 华为开发者空间产品总监
数字化转型进程持续加速，驱动着技术革新发展，华为开发者空间如何巧妙整合鸿蒙、昇腾、鲲鹏等核心资源，打破平台间的壁垒，实现跨平台协同？在科技迅猛发展的今天，开发者们如何迅速把握机遇，实现高效、创新的技术突破？DTT 年度收官盛典，将与大家共同探索华为开发者空间的创新奥秘。
回顾中
热门标签