<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[清扬叶]]></title><description><![CDATA[工程师]]></description><link>https://blog.youkuaiyun.com/dengbixuan</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; dengbixuan]]></copyright><item><title><![CDATA[RESTful接口设计]]></title><link>https://blog.youkuaiyun.com/dengbixuan/article/details/121561556</link><guid>https://blog.youkuaiyun.com/dengbixuan/article/details/121561556</guid><author>dengbixuan</author><pubDate>Fri, 26 Nov 2021 15:35:37 +0800</pubDate><description><![CDATA[RESTful是一种流行的接口设计规范，不是标准，只是提供了一组设计原则和约束条件。

RESTful解决了什么问题？
后端服务接口设计混乱、不易理解、扩展不方便、没有一个标准、命名混乱。使用了Restful风格设计接口可以让后端提供的接口更加结构清晰、符合标准、易于理解、扩展方便。

Restful接口主要特征：
1 以资源为基础：面向资源来设计接口，资源可以是图片，后端的服务对象，用户数据等。
2 统一的接口：对资源的操作包括获取、创建、修改和删除，这些操作正好对应HTTP协议提供的GET、POST、P]]></description><category></category></item><item><title><![CDATA[分布式理论---Quorum 机制]]></title><link>https://blog.youkuaiyun.com/dengbixuan/article/details/120543810</link><guid>https://blog.youkuaiyun.com/dengbixuan/article/details/120543810</guid><author>dengbixuan</author><pubDate>Wed, 29 Sep 2021 10:36:31 +0800</pubDate><description><![CDATA[一. WARO机制

   WARO(Write All Read one)是一种简单的副本控制协议，当Client请求向某副本写数据时(更新数据)，只有当所有的副本都更新成功之后，这次写操作才算成功，否则视为失败。

从这里可以看出两点：①写操作很脆弱，因为只要有一个副本更新失败，此次写操作就视为失败了。②读操作很简单，因为，所有的副本更新成功，才视为更新成功，从而保证所有的副本一致。这样，只需要读任何一个副本上的数据即可。假设有N个副本，N-1个都宕机了，剩下的那个副本仍能提供读服务；但是只要有...]]></description><category></category></item><item><title><![CDATA[云原生---Serverless]]></title><link>https://blog.youkuaiyun.com/dengbixuan/article/details/120536911</link><guid>https://blog.youkuaiyun.com/dengbixuan/article/details/120536911</guid><author>dengbixuan</author><pubDate>Tue, 28 Sep 2021 20:28:13 +0800</pubDate><description><![CDATA[Serverless是指构建和运行不需要服务器管理的应用程序的概念。

   Serverless 产品表的是无需理解、管理服务器，按需使用，按使用付费的产品。Serverless 产品中，其实也可以包含存储、计算等多种类型的产品。而典型的计算产品，就是云函数这种形态。

   云函数，或者称为函数即服务 (Function as a Service)，它和后端即服务 (Backend as a Service) 一起，都可以称为 Serverless 产品。通过组合使用这些...]]></description><category></category></item><item><title><![CDATA[云原生---ServiceMesh]]></title><link>https://blog.youkuaiyun.com/dengbixuan/article/details/120536733</link><guid>https://blog.youkuaiyun.com/dengbixuan/article/details/120536733</guid><author>dengbixuan</author><pubDate>Tue, 28 Sep 2021 20:22:51 +0800</pubDate><description><![CDATA[Service Mesh的定义：

  服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证请求在这些拓扑中可靠地穿梭。在实际应用当中，服务网格通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但对应用程序透明。

  Service Mesh 将底层那些难以控制的网络通讯统一管理，诸如：流量管控，丢包重试，访问控制等。而上层的应用层协议只需关心业务逻辑即可。Service Mesh 是一个用于处理服务间通信的基础设施层，它负责为构建复杂的云原...]]></description><category></category></item><item><title><![CDATA[微服务架构---康威定律]]></title><link>https://blog.youkuaiyun.com/dengbixuan/article/details/120536188</link><guid>https://blog.youkuaiyun.com/dengbixuan/article/details/120536188</guid><author>dengbixuan</author><pubDate>Tue, 28 Sep 2021 19:54:36 +0800</pubDate><description><![CDATA[康威定律核心观点，如下：

第一定律：Communication dictates design（组织沟通方式会通过系统设计表达出来）

第二定律：There is never enough time to do something right, but there is always enough time to do it over（时间再多一件事情也不可能做的完美，但总有时间做完一件事情）

第三定律：There is a homomorphism from the linear graph of..]]></description><category></category></item><item><title><![CDATA[声明式编程VS命令式编程]]></title><link>https://blog.youkuaiyun.com/dengbixuan/article/details/120536000</link><guid>https://blog.youkuaiyun.com/dengbixuan/article/details/120536000</guid><author>dengbixuan</author><pubDate>Tue, 28 Sep 2021 19:37:59 +0800</pubDate><description><![CDATA[In computer science, declarative programming is a programming paradigm — a style of building the structure and elements of computer programs—that expresses the logic of a computation without describing its control flow. This is in contrast with imperative.]]></description><category></category></item><item><title><![CDATA[分布式算法---zab算法]]></title><link>https://blog.youkuaiyun.com/dengbixuan/article/details/120535646</link><guid>https://blog.youkuaiyun.com/dengbixuan/article/details/120535646</guid><author>dengbixuan</author><pubDate>Tue, 28 Sep 2021 19:17:58 +0800</pubDate><description><![CDATA[ZAB 协议全称：Zookeeper Atomic Broadcast（Zookeeper 原子广播协议）。


Zookeeper 是一个为分布式应用提供高效且可靠的分布式协调服务。在解决分布式一致性方面，Zookeeper 并没有使用 Paxos ，而是采用了 ZAB 协议。 ZAB 协议定义：ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持 崩溃恢复 和 原子广播 协议。下面我们会重点讲这两个东西。 基于该协议，Zookeeper 实现了一种 主备模式 的系统架构来保持集群中各个]]></description><category></category></item><item><title><![CDATA[分布式算法---gossip 协议]]></title><link>https://blog.youkuaiyun.com/dengbixuan/article/details/120535210</link><guid>https://blog.youkuaiyun.com/dengbixuan/article/details/120535210</guid><author>dengbixuan</author><pubDate>Tue, 28 Sep 2021 18:50:49 +0800</pubDate><description><![CDATA[gossip 协议（gossip protocol）又称 epidemic 协议（epidemic protocol），是基于流行病传播方式的节点或者进程之间信息交换的协议，在分布式系统中被广泛使用，比如我们可以使用 gossip 协议来确保网络中所有节点的数据一样。

Gossip协议是基于六度分隔理论（Six Degrees of Separation）哲学的体现，简单的来说，一个人通过6个中间人可以认识世界任何人。数学公式是：

n表示复杂度，N表示人的总数，W表示每个人的联系宽度。依据邓巴数，即每个]]></description><category></category></item><item><title><![CDATA[分布式算法---Raft]]></title><link>https://blog.youkuaiyun.com/dengbixuan/article/details/120522125</link><guid>https://blog.youkuaiyun.com/dengbixuan/article/details/120522125</guid><author>dengbixuan</author><pubDate>Tue, 28 Sep 2021 15:34:00 +0800</pubDate><description><![CDATA[Raft是工程上使用较为广泛的强一致性、去中心化、高可用的分布式协议。在这里强调了是在工程上，因为在学术理论界，最耀眼的还是大名鼎鼎的Paxos。但Paxos是：少数真正理解的人觉得简单，尚未理解的人觉得很难，大多数人都是一知半解。本人也花了很多时间、看了很多材料也没有真正理解。直到看到raft的论文，两位研究者也提到，他们也花了很长的时间来理解Paxos，他们也觉得很难理解，于是研究出了raft算法。

    raft是一个共识算法（consensus algorithm），所谓...]]></description><category></category></item><item><title><![CDATA[分布式算法---拜占庭将军问题]]></title><link>https://blog.youkuaiyun.com/dengbixuan/article/details/120516007</link><guid>https://blog.youkuaiyun.com/dengbixuan/article/details/120516007</guid><author>dengbixuan</author><pubDate>Mon, 27 Sep 2021 19:59:55 +0800</pubDate><description><![CDATA[一. 拜占庭将军问题

   拜占庭将军问题（Byzantine failures），是由莱斯利·兰伯特提出的点对点通信中的基本问题。含义是在存在消息丢失的不可靠信道上试图通过消息传递的方式达到一致性是不可能的[1]。

   1.简介

   拜占庭将军问题是一个协议问题，拜占庭帝国军队的将军们必须全体一致的决定是否攻击某一支敌军。问题是这些将军在地理上是分隔开来的，并且将军中存在叛徒。叛徒可以任意行动以达到以下目标：欺骗某些将军采取进攻行动；促成一个不是所有将军都同意的决定，...]]></description><category></category></item><item><title><![CDATA[分布式算法---Multi Paxos]]></title><link>https://blog.youkuaiyun.com/dengbixuan/article/details/120515125</link><guid>https://blog.youkuaiyun.com/dengbixuan/article/details/120515125</guid><author>dengbixuan</author><pubDate>Mon, 27 Sep 2021 19:12:04 +0800</pubDate><description><![CDATA[Multi Paxos 算法是一种Paxos算法的改进版本。

   Multi Paxos 对 Basic Paxos 的核心改进是增加了“选主”的过程，提案节点会通过定时轮询（心跳），确定当前网络中的所有节点里是否存在有一个主提案节点，一旦没有发现主节点存在，节点就会在心跳超时后使用 Basic Paxos 中定义的准备、批准的两轮网络交互过程，向所有其他节点广播自己希望竞选主节点的请求，希望整个分布式系统对“由我作为主节点”这件事情协商达成一致共识，如果得到了决策节点中多数派的批准，...]]></description><category></category></item><item><title><![CDATA[分布式算法---Paxos 算法]]></title><link>https://blog.youkuaiyun.com/dengbixuan/article/details/120512270</link><guid>https://blog.youkuaiyun.com/dengbixuan/article/details/120512270</guid><author>dengbixuan</author><pubDate>Mon, 27 Sep 2021 17:25:08 +0800</pubDate><description><![CDATA[Paxos发布

Lamport 最初在 1990 年首次发表了 Paxos 算法，选的论文题目就是“The Part-Time Parliament”。由于算法本身极为复杂，用希腊城邦作为比喻反而使得描述更为晦涩，论文的三个审稿人一致要求他把希腊城邦的故事删除掉，这令 Lamport 感觉颇为不爽，然后干脆就撤稿不发了，所以 Paxos 刚刚被提出的时候并没有引起什么反响。八年之后（1998 年），Lamport 再次将此文章重新整理后投到《ACM Transactions on Computer Sys]]></description><category></category></item><item><title><![CDATA[微服务架构---服务注册和服务发现]]></title><link>https://blog.youkuaiyun.com/dengbixuan/article/details/120495369</link><guid>https://blog.youkuaiyun.com/dengbixuan/article/details/120495369</guid><author>dengbixuan</author><pubDate>Mon, 27 Sep 2021 11:10:20 +0800</pubDate><description><![CDATA[微服务架构中最核心的部分是服务治理，服务治理最基础的组件是服务注册和服务发现。随着微服务架构的发展，出现了很多微服务架构的解决方案，其中包括我们熟知的Dubbo和Spring Cloud。 关于服务注册和服务发现的解决方案，dubbo支持了zookeeper、redis、multicast和simple，官方推荐zookeeper。Spring cloud支持了Eureka、zookeeper、Consul、nacos，官方推荐了Eureka。Spring Cloud Ali为了同时支持dubbo...]]></description><category></category></item><item><title><![CDATA[elastic-job作业分片算法]]></title><link>https://blog.youkuaiyun.com/dengbixuan/article/details/109327292</link><guid>https://blog.youkuaiyun.com/dengbixuan/article/details/109327292</guid><author>dengbixuan</author><pubDate>Wed, 28 Oct 2020 10:13:28 +0800</pubDate><description><![CDATA[elastic-job作业分片策略

elastic-job有以下分片策略：
1. AverageAllocationJobShardingStrategy分片策略
2. OdevitySortByNameJobShardingStrategy分片策略
3. RotateServerByNameJobShardingStrategy分片策略
并且支持还支持自定义分片策略

AverageAllocationJobShardingStrategy分片策略,即基于平均分配算法的分片策略，是默认的分片策略。
对应]]></description><category></category></item><item><title><![CDATA[LeetCode 247. 中心对称数]]></title><link>https://blog.youkuaiyun.com/dengbixuan/article/details/107223058</link><guid>https://blog.youkuaiyun.com/dengbixuan/article/details/107223058</guid><author>dengbixuan</author><pubDate>Thu, 09 Jul 2020 10:46:51 +0800</pubDate><description><![CDATA[1. 题目

中心对称数是指一个数字在旋转了 180 度之后看起来依旧相同的数字（或者上下颠倒地看）。

找到所有长度为 n 的中心对称数。

示例 :
输入: n = 2
输出: ["11","69","88","96"]

2. 解题

add1 = {"0","1","8"}，add2 = {"00","11","69","88","96"}
	i 是奇数，我们在 i-1 偶数的基础上每个数中间位置 add1
	i 是偶数，我们在 i-2 偶数的基础上每个数中间位置 add2

package co.]]></description><category></category></item><item><title><![CDATA[linux系统句柄数命令]]></title><link>https://blog.youkuaiyun.com/dengbixuan/article/details/106838625</link><guid>https://blog.youkuaiyun.com/dengbixuan/article/details/106838625</guid><author>dengbixuan</author><pubDate>Thu, 18 Jun 2020 16:58:29 +0800</pubDate><description><![CDATA[查看当前系统支持打开的最大句柄数

Linux的/proc/sys/fs/file-max决定了当前内核可以打开的最大的文件句柄数。
cat /proc/sys/fs/file-max

修改系统最大打开文件描述符数：
临时设置：echo 1000000 &gt; /proc/sys/fs/file-max
永久设置：修改/etc/sysctl.conf文件，增加fs.file-max = 1000000


查看系统fd总数：


准确的查看fd使用总数的命令是：
cat /proc/sys/fs/f..]]></description><category></category></item><item><title><![CDATA[lsof命令使用场景]]></title><link>https://blog.youkuaiyun.com/dengbixuan/article/details/106817389</link><guid>https://blog.youkuaiyun.com/dengbixuan/article/details/106817389</guid><author>dengbixuan</author><pubDate>Wed, 17 Jun 2020 20:09:34 +0800</pubDate><description><![CDATA[lsof命令：

是一个列出当前系统打开文件的工具。在linux环境下，任何事物都以文件的形式存在，通过文件不仅仅可以访问常规数据，还可以访问网络连接和硬件。



lsof输出列的含义:



COMMAND：进程的名称 PID：进程标识符

USER：进程所有者

FD：文件描述符，应用程序通过文件描述符识别该文件。如cwd、txt等 TYPE：文件类型，如DIR、REG等

DEVICE：指定磁盘的名称

SIZE：文件的大小

NODE：索引节点（文件在磁盘上的标识）

NAME：打开文件的确...]]></description><category></category></item><item><title><![CDATA[nginx 轮询转发请求不均衡]]></title><link>https://blog.youkuaiyun.com/dengbixuan/article/details/106783188</link><guid>https://blog.youkuaiyun.com/dengbixuan/article/details/106783188</guid><author>dengbixuan</author><pubDate>Tue, 16 Jun 2020 11:05:50 +0800</pubDate><description><![CDATA[后端服务配置，一台116服务器用于nginx转发请求，使用轮询的负载均衡策略；两台后端API接口服务器57和117，用于处理请求。



   现象背景：当对指定接口进行压力测试的时候，会出现绝大部分的请求都转发到57服务器，而117服务器上只有少量的请求。



  问题定位：查看nginx的error日志发现，出现大量报错：2020/06/16 14:23:00 [error] 4950#4950: *4162133210 no live upstreams while...]]></description><category></category></item><item><title><![CDATA[redis引入lua优势]]></title><link>https://blog.youkuaiyun.com/dengbixuan/article/details/106389086</link><guid>https://blog.youkuaiyun.com/dengbixuan/article/details/106389086</guid><author>dengbixuan</author><pubDate>Wed, 27 May 2020 19:51:30 +0800</pubDate><description><![CDATA[Lua是一种功能强大，高效，轻量级，可嵌入的脚本语言。redis中Lua 脚本功能是 Reids 2.6 版本的最大亮点， 通过内嵌对 Lua 环境的支持， Redis 解决了长久以来不能高效地处理 CAS （check-and-set）命令的缺点， 并且可以通过组合使用多个命令， 轻松实现以前很难实现或者不能高效实现的模式。 

   redis中引入lua的优势：

减少网络开销：多个请求通过脚本一次发送，减少网络延迟
	原子操作：将脚本作为一个整体执行，中间不会插入其他命令，无需...]]></description><category></category></item><item><title><![CDATA[redis应该如何删除集合]]></title><link>https://blog.youkuaiyun.com/dengbixuan/article/details/106388823</link><guid>https://blog.youkuaiyun.com/dengbixuan/article/details/106388823</guid><author>dengbixuan</author><pubDate>Wed, 27 May 2020 19:24:21 +0800</pubDate><description><![CDATA[背景

在redis的命令接口中，没有专门针对list，set，hash等数据结构的key删除命令，只有指定到删除具体的对象的操作命令。
比如删除list列表的元素命令LREM，删除set集合中一个或多个元素命令SREM，删除hash中一个或多个元素HDEL。
而在redis的一些使用中还是可能遇到对这些集合类对象整体删除的场景如：
场景1：当用户的信息使用hash结构储存时，需要删除整个用户的信息
场景2：删除大V的粉丝列表

DEL

在redis4.0之前可以用del命令直接删除key，但是由于re.]]></description><category></category></item></channel></rss>