系统设计 on

Oauth2.0

Tue, 28 Mar 2023 00:00:00 +0000

cat Oauth2.0
#

简介
#

OAuth2.0协议是一个开放标准，允许用户授权第三方程序访问他们存储在另外的服务提供者上的信息，而不需要将用户和密码提供给第三方应用或分享他们数据的所有内容。

运用场景
#

几乎每个人在使用一个APP或网页应用的时候都看过他们支持第三方登录比如微信登录、 QQ 登录、微博登录、 Google 账号登录、github 授权登录等等。这些都是典型的 OAuth2 使用场景。

授权流程
#

这里以网页应用微信授权登录为例。

准备工作
#

在进行微信OAuth2.0授权登录接入之前，在微信开放平台注册开发者帐号，并拥有一个已审核通过的网站应用，并获得相应的 AppID 和AppSecret，申请微信登录且通过审核后，可开始接入流程。

熔断与限流

Wed, 08 Mar 2023 00:00:00 +0000

微服务限流
#

限流顾名思义，就是对请求或并发数进行限制；通过对一个时间窗口内的请求量进行限制来保障系统的正常运行。如果我们的服务资源有限、处理能力有限，就需要对调用我们服务的上游请求进行限制，以防止自身服务由于资源耗尽而停止服务。在限流中有两个概念需要了解：

阈值：在一个单位时间内允许的请求量。如 QPS 限制为10，说明 1 秒内最多接受 10 次请求。
拒绝策略：超过阈值的请求的拒绝策略，常见的拒绝策略有直接拒绝、排队等待等。

1. 固定窗口算法
#

固定窗口算法又叫计数器算法，是一种简单方便的限流算法。主要通过一个支持原子操作的计数器来累计 1 秒内的请求次数，当 1 秒内计数达到限流阈值时触发拒绝策略。每过 1 秒，计数器重置为 0 开始重新计数。

一致性哈希

Mon, 06 Mar 2023 00:00:00 +0000

一致性hash
#

如何分配请求
#

当数据库的量太大时，可能会考虑分库分表，当分库分表之后，那就需要考虑对应的数据如何存储的问题。这里以用户库分表为例。当一个获取用户信息的请求过来，如何根据user_id去对应的表找对应的用户信息？

其实不仅是分库分表，在一些负载均衡中间件里，也有同样的问题（比如利用用户ip来决定请求流量往哪个服务器走）。

普通哈希
#

很容易想到，解决请求如何分配的一个解决方法就是将sharding_key哈希，得到hash值后对节点数进行取模运算。获取节点的公式即为：

hash(key) % num_of_nodes

还是以用户表为例子，假设有将用户表分成三个表，分别是user_table_1，user_table_2，user_table_3。具体计算流程如图所示。

普通哈希的方法根据user_id定位到具体的表，这样看似是解决了问题，但是如果用户量突然增长，需要再加一张表时，原先的表数量将由3变成4，sharding的计算方式也变hash(user_id)%4，并且需要进行大量的数据迁移。

要解决这个问题，需要对user表的数据重新按照节点4进行迁移，坏情况下所有数据都需要迁移，所以它的数据迁移规模是 O(M)，这样数据的迁移成本太高了。

一致性哈希
#

一致性哈希可以解决我们当节点变化时数据迁移量太大的问题。**一致性哈希的也是用取模的方法，但它不是对节点数取模，而是对2^64-1取模。**一致性哈希将哈希值对2^64-1所有的结果组织成一个圆环，称为哈希环。

web安全

Thu, 02 Mar 2023 00:00:00 +0000

web安全
#

1. CSRF攻击
#

CSRF是跨站请求伪造的缩写，也被称为XSRF，是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。**因为CSRF攻击利用的是冲着浏览器分不清发起请求是不是真正的用户本人。**也就是说，简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。

a. CSRF的基本攻击原理
#

用户Alice登录和访问某银行网站A，保留cookie。
Alice被某些信息诱导访问危险网站B。
危险网站B上有一个<img>标签：
这个标签的src不指向一张图片，而是一个http请求，这个请求向银行要求将Alice的1000元转给Badman，由于Alice的浏览器上有cookie，这样浏览器发出的这个请求就能得到响应执行。
这样Alice的钱就被偷了。

b. CSRF的防范
#

黑客仅仅靠CSRF发起攻击，他只能借助受害者的cookie骗取服务器的信任，但是黑客并不能凭借拿到cookie，也看不到 cookie的内容。这就告诉我们，我们要保护的对象是那些可以直接产生数据改变的服务，而对于读取数据的服务，则不需要进行csrf的保护。而保护的关键，是 在请求中放入黑客所不能伪造的信息。

GeoHash算法

Wed, 22 Feb 2023 00:00:00 +0000

GeoHash
#

背景
#

经纬度是经度与纬度的合称组成一个坐标系统，称为地理坐标系统，它是一种利用三度空间的球面来定义地球上的空间的球面坐标系统，能够标示地球上的任何一个位置。

GeoHash
#

GeoHash是空间索引的一种方式，其基本原理是将地球理解为一个二维平面，通过把二维的空间经纬度数据编码为一个字符串，可以把平面递归分解成更小的子块，每个子块在一定经纬度范围内拥有相同的编码。简单地说就是将二维的坐标转换成一维坐标，从而提高对位置数据的检索效率。

编码规则
#

先将纬度范围(-90, 90)平分成两个区间(-90, 0)和(0, 90)，如果目标维度位于前一个区间，则编码为0，否则编码为1，然后根据目标纬度所落的区间再平均分成两个区间进行编码，以此类推，直到精度满足要求，经度也用同样的算法，对(-180, 180)依次细分，然后合并经度和纬度的编码，奇数位放纬度，偶数位放经度，组成一串新的二进制编码，按照Base32进行编码。

编码示例
#

以经纬度值：（116.389550， 39.928167）进行算法说明，对纬度39.928167进行逼近编码 (地球纬度区间是[-90,90]）

设计模式之简介

Mon, 20 Feb 2023 00:00:00 +0000

设计模式
#

简介
#

什么是设计模式？

“软件设计模式(Design Pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，使用设计模式是为了可重用代码、让代码更容易被他人理解并且保证代码可靠性。”

一句大白话可以总结：“在一定环境下，用固定套路解决问题。”

分类
#

常用的设计模式共有23种，其中包括：

创建型(Creational)模式：如何创建对象；
1. 单例模式
2. 简单工厂模式
3. 工厂方法模式
4. 抽象工厂模式
结构型(Structural )模式：如何实现类或对象的组合；
1. 代理模式
2. 装饰模式
3. 适配器模式
4. 外观模式
行为型(Behavioral)模式：类或对象怎样交互以及怎样分配职责。
1. 模版方法模式
2. 命令模式
3. 外观模式
4. 观察者模式

原则
#

名称	定义
单一职责原则	类的职责单一，对外只提供一种功能，而引起类变化的原因都应该只有一个。
开闭原则	类的改动是通过增加代码进行的，而不是修改源代码。
里氏代换原则	任何抽象类（interface接口）出现的地方都可以用他的实现类进行替换，实际就是虚拟机制，语言级别实现面向对象功能。
依赖倒转原则	依赖于抽象(接口)，不要依赖具体的实现(类)，也就是针对接口编程。
接口隔离原则	不应该强迫用户的程序依赖他们不需要的接口方法。一个接口应该只提供一种对外功能，不应该把所有操作都封装到一个接口中去。
合成复用原则	如果使用继承，会导致父类的任何变换都可能影响到子类的行为。如果使用对象组合，就降低了这种依赖关系。对于继承和组合，优先使用组合。
迪米特法则	一个对象应当对其他对象尽可能少的了解，从而降低各个对象之间的耦合，提高系统的可维护性（黑盒原理）

延迟队列

Wed, 15 Feb 2023 00:00:00 +0000

延迟队列
#

定义
#

队列是一种FIFO的数据结构，即先进队的数据先出队。延时队列相对于普通队列的来说，最大的区别在于他的延迟属性。延迟队列在入队的时候会指定一个延迟时间，表示其希望在经过改指定时间后处理这个任务。从某种意义上来讲，延迟队列的结构并不像一个队列，而更像一种以时间为权重的有序堆结构。

应用场景
#

在淘宝、京东等购物平台上下单，15分钟内未付款，订单会自动取消。
打车的时候，在规定时间没有车主接单，平台会取消你的单并提醒你暂时没有车主接单。
点外卖的时候，如果商家在10分钟还没接单，就会自动取消订单。
收快递的时候，如果我们没有点确认收货，在一段时间后程序会自动完成订单。
在平台完成订单后，如果我们没有在规定时间评论商品，会自动默认买家不评论。

如何实现
#

如果是数据量较小且时实时性不高的场景，可以使用轮询的方式，比如每秒轮询数据库的所有数据，然后处理到期的任务。轮询的方式只能处理数据量较小且实时性不高的数据，如果像处理淘宝订单15分钟内未付款自动取消订单这种任务，就需要更加高效的处理方式了。

1. Redis的Zset
#

Redis中有一种有序集合的数据结构zset，zset中每一个元素都有对应的score，zset中所有的数据都是按照score来排序的。

分布式理论

Tue, 14 Feb 2023 00:00:00 +0000

分布式理论
#

CAP理论
#

C：Consistency，即一致性。所有节点都访问同一份数据节点。
A：Availability，即可用性。每次请求都能获取到非错的响应，但不保证获取的数据为最新的数据。
P：Partition tolerence，即分区容错性。在某个节点或者网络分区故障的时候，仍然能够对外提供一致性和可用性服务，也就是说部分故障不影响整体的使用。

根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项。理解CAP理论的最简单方式是想像两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失P性质。

BASE理论
#

BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网分布式系统实践的总结，是基于CAP定律逐步演化而来。其核心思想是即使无法做到强一致性，但每个应用都可以根据自身业务特点，才用适当的方式来使系统打到最终一致性。

BA：Basically Available，即基本可用。假设系统某个模块出现了不可预知的故障，但其他模块依然可用。如双十一活动时，评论模块出现故障，但不会影响交易、商品等核心模块的使用。
S：Soft Status，即软状态。指允许系统中出现中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
E：Eventually Consistent，即最终一致。上面讲到的软状态不可能一直是软状态，必须有时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性，因此所有客户端对系统的数据访问最终都能够获取到最新的值，而这个时间期限取决于网络延时，系统负载，数据复制方案等因素。

总的来说，BASE 理论面向的是大型高可用可扩展的分布式系统，和传统事务的 ACID 是相反的，它完全不同于 ACID 的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间是不一致的。

Raft协议
#

分布式存统通常通过维护多个副本来进行容错，提高系统的可用性。要实现此目标，就必须要解决分布式系统的最核心问题：维护多个副本的一致性。Raft协议将一致性协议的核心内容分拆成为几个关键阶段，以简化流程，提高协议的可理解性。

DDD领域驱动设计

Thu, 22 Dec 2022 00:00:00 +0000

领域驱动设计
#

1.分层架构
#

用户界面层：网络协议的转化/统一鉴权/Session 管理/限流配置/前置缓存/异常转换
应用层：业务流程编排（仅编排，不能存在业务逻辑）/ DTO 出入转化
领域层：领域模型/领域服务/仓储和防腐层的接口定义
基础设施层：仓储和防腐层接口实现/存储等基础层能力

2. todo…
#

设计模式之行为型模式

Tue, 15 Nov 2022 00:00:00 +0000

行为型模式
#

1.模版方法模式
#

在模板模式（Template Pattern）中，一个抽象类公开定义了执行它的方法的方式/模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行。模版方法模式中的角色与职责如下：

AbstractClass（抽象类）：在抽象类中定义了一系列基本操作(PrimitiveOperations)，这些基本操作可以是具体的，也可以是抽象的，每一个基本操作对应算法的一个步骤，在其子类中可以重定义或实现这些步骤。同时，在抽象类中实现了一个模板方法(Template Method)，用于定义一个算法的框架，模板方法不仅可以调用在抽象类中实现的基本方法，也可以调用在抽象类的子类中实现的基本方法，还可以调用其他对象中的方法。
ConcreteClass（具体子类）：它是抽象类的子类，用于实现在父类中声明的抽象基本操作以完成子类特定算法的步骤，也可以覆盖在父类中已经实现的具体基本操作。

package main

import "fmt"

type WorkInterface interface {
	GetUp()
	Work()
	Sleep()
}

type worker struct {
	WorkInterface
}

func NewWorker(w WorkInterface) worker {
	return worker{WorkInterface: w}
}

func (w worker) Daily()  {
	w.GetUp()
	w.Work()
	w.Sleep()
}


//具体子类
type Coder struct {}

func (Coder) GetUp()  {
	fmt.Println("coder get up")
}

func (Coder) Work()  {
	fmt.Println("coder work")
}

func (Coder) Sleep()  {
	fmt.Println("coder sleep")
}



type Farmer struct {}

func (Farmer) GetUp()  {
	fmt.Println("farmer get up")
}

func (Farmer) Work()  {
	fmt.Println("farmer work")
}

func (Farmer) Sleep()  {
	fmt.Println("farmer sleep")
}

func main()  {
	worker1 := NewWorker(Coder{})
	worker1.Daily()

	fmt.Println("---------------")

	worker2 := NewWorker(Farmer{})
	worker2.Daily()
}

优点：

缓存策略

Thu, 10 Nov 2022 00:00:00 +0000

缓存策略
#

1. 双写策略
#

双写即当数据修改时，即要更新数据库也要更新缓存。下面看看具体的双写的两种场景。

a. 先更新数据库，再更新缓存
#

请求A先更数据库为1
请求B更新数据库为2
请求B先更新缓存为2
请求A更新缓存为1

先更新数据库，再更新缓存这种策略会导致数据库与缓存不一致

b. 先更新缓存，再更新数据库
#

请求A先更新缓存为1
请求B更新缓存为2
请求B先更新数据库为2
请求A更新数据库为1

与先更新数据库，再更新缓存这种策略一样，先更新缓存，再更新数据库会因为并发原因导致数据库与缓存数据不一致。

设计模式之创建型模式

Tue, 01 Nov 2022 00:00:00 +0000

创建型模式
#

1.单例模式
#

单例模式保证知有一个类、只有一个实例存在，同时提供能对该实例加以访问的全局访问方法。单例模式的三个要点：

这个类只能有一个实例
这个类必须自己创建这个实例
这个类必须自行向整个系统提供这个实例

下面是一个单例模式的demo

package singelton

import "fmt"

type singelton struct {}

func (*singelton) Foo()  {
	fmt.Println("call singleton.Foo")
}

func (*singelton) Bar()  {
	fmt.Println("call singleton.Bar")
}

var instance = new(singelton)

func GetInstance() *singelton {
	return instance
}

//.... in main.go
func main() {
  s := singelton.GetInstance()
  s.Foo()
  s.Bar()
}

上面这个demo模式展示了单例模式的一种，属于饿汉模式。其含义是在初始化单例唯一指针的时候，就已经提前开辟好了一个对象，申请了内存。饿汉式的好处是，不会出现线程并发创建，导致多个单例的出现，但是缺点是如果这个单例对象在业务逻辑没有被使用，也会客观的创建一块内存对象。那么与之对应的模式叫懒汉模式，代码如下：

幂等设计

Wed, 26 Oct 2022 00:00:00 +0000

幂等设计
#

什么是幂等？
#

幂等指的是对某个资源来说，一次请求与多次请求，具有相同的副作用。用数学的语言的来表示就是f(x) = f(f(x))。为什么需要幂等？当我们将系统节藕隔离后，服务间的调用可能有三种状态：成功、失败、超时。前两者是明确的状态，而超时则是一种不明确的状态，可能这个请求还没到达服务端就已经超时了，也有可能请求已经到服务端，但是在返回给客户端的过程中超时或者丢包了，客户端完全不知道服务端是否有接受到数据。举几个例子：

订单支付时，第一次支付超时了，然后客户端再次调用，是否会多扣一次钱？
在页面提交form表单时，保存按钮不小心快速按了两次，表中产生了两条重复的数据数据。
mq消费的时候，有时候会读取到重复的消息，造成重复消费。

接口性幂等是指用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。

如何保证幂等？
#

1. insert前先select
#

在insert数据前，先用唯一id（例如订单id）查询一下数据库是否有这个订单记录，如果没有则insert，否则返回订单信息。这种方法很简单，但是很明显，在并发的情况下一样会有产生重复订单。

2. 悲观锁
#

当有多个重复请求到达时，只有一个请求能够进行操作。比如在支付场景中，用户A的账户中有150元，某个请求扣件100元后，此时账户还剩50元。如果出现多次重复的请求，那么用户的余额可能出现负数。为了解决这个问题，可以使用悲观锁先锁住用户的账号，MySQL中可以用如下sql语句锁住数据。

设计模式之结构型模式

Wed, 26 Oct 2022 00:00:00 +0000

结构型模式
#

1.代理模式
#

代理模式可以为其他对象提供一种代理以控制对这个对象的访问。所谓代理，是指具有与代理元（被代理的对象）具有相同的接口的类，客户端必须通过代理与被代理的目标类交互，而代理一般在交互的过程中（交互前后），进行某些特别的处理。代理模式的角色与职责如下：

Subject（抽象主题角色）：真实主题与代理主题的共同接口。
RealSubject（真实主题角色）：定义了代理角色所代表的真实对象。
Proxy（代理主题角色）：含有对真实主题角色的引用，代理角色通常在将客户端调用传递给真实主题对象之前或者之后执行某些操作，而不是单纯返回真实的对象。

package main

import "fmt"

type Goods struct {
	Kind string //商品种类
	Fact bool //商品真伪
}

// =========== 抽象层 ===========
//抽象的购物主题Subject
type Shopping interface {
	Buy(goods *Goods) //某任务
}

// =========== 实现层 ===========
type KoreaShopping struct {}
func (ks *KoreaShopping) Buy(goods *Goods) {
	fmt.Println("去韩国进行了购物, 买了 ", goods.Kind)
}

type AmericanShopping struct {}
func (as *AmericanShopping) Buy(goods *Goods) {
	fmt.Println("去美国进行了购物, 买了 ", goods.Kind)
}

type AfricaShopping struct {}
func (as *AfricaShopping) Buy(goods *Goods) {
	fmt.Println("去非洲进行了购物, 买了 ", goods.Kind)
}

//代理层
type OverseasProxy struct {
	shopping Shopping //代理某个主题，这里是抽象类型
}

func NewProxy(shopping Shopping) *OverseasProxy {
	return &OverseasProxy{
		shopping: shopping,
	}
}

func (op *OverseasProxy) Buy(goods *Goods)  {
	if op.distinguish(goods) { //代理验货
		op.shopping.Buy(goods) //进行购买 调用真实主题角色的具体任务
		op.check(goods) //海关安检
	}
}

//代理验货
func (op *OverseasProxy) distinguish(goods *Goods) bool {
	fmt.Println("对[", goods.Kind,"]进行了辨别真伪.")
	if goods.Fact == false {
		fmt.Println("发现假货",goods.Kind,", 不应该购买。")
	}
	return goods.Fact
}

//安检流程
func (op *OverseasProxy) check(goods *Goods) {
	fmt.Println("对[",goods.Kind,"] 进行了海关检查， 成功的带回祖国")
}

func main()  {
	g1 := &Goods{Kind: "韩国面膜", Fact: false}
	g2 := &Goods{Kind: "米国鞋子", Fact: true}

	//不使用代理模式
	koreaShopping := &KoreaShopping{}
	if g1.Fact == true {
		fmt.Println("对[", g1.Kind,"]进行了辨别真伪.")
		koreaShopping.Buy(&g1)
		fmt.Println("对[",g1.Kind,"] 进行了海关检查， 成功的带回祖国")
	}


	//使用代理模式
	proxy1 := NewProxy(&KoreaShopping{})
	proxy1.Buy(g1)

	proxy2 := NewProxy(&AmericanShopping{})
	proxy2.Buy(g2)
}

优点：

分布式ID

Thu, 13 Oct 2022 00:00:00 +0000

分布式ID
#

1. 什么是分布式ID
#

在我们业务数据量不大的时候，单库单表完全可以支撑现有业务，数据再大一点搞个MySQL主从同步读写分离也能对付。但随着数据日渐增长，主从同步也扛不住了，就需要对数据库进行分库分表，但分库分表后需要有一个唯一ID来标识一条数据，数据库的自增ID显然不能满足需求。特别一点的如订单、优惠券也都需要有唯一ID做标识。此时一个能够生成全局唯一ID的系统是非常必要的。那么这个全局唯一ID就叫分布式ID。

分布式ID需要满足哪些条件？

全局唯一：必须保证ID是全局性唯一的，基本要求
高性能：高可用低延时，ID生成响应要块，否则反倒会成为业务瓶颈
高可用：100%的可用性是骗人的，但是也要无限接近于100%的可用性
好接入：要秉着拿来即用的设计原则，在系统设计和实现上要尽可能的简单
趋势递增：最好趋势递增（防止索引数据页频繁发生页分裂），这个要求就得看具体业务场景了，一般不严格要求

2. 如何生成分布式ID
#

a. uuid
#

想要得到一个具有唯一性的ID，首先被想到可能就是UUID，毕竟它有着全球唯一的特性。那么UUID可以做分布式ID吗？答案是可以的，但是并不推荐。

优点：

生成足够简单，本地生成无网络消耗，具有唯一性

缺点：

LSM树

Mon, 10 Oct 2022 00:00:00 +0000

LSM树
#

简介
#

LSM树，即日志结构合并树(Log-Structured Merge-Tree)。其实它并不属于一个具体的数据结构，它更多是一种数据结构的设计思想。大多NoSQL数据库核心思想都是基于LSM来做的，只是具体的实现不同。传统关系型数据库使用btree或一些变体作为存储结构，能高效进行查找。但保存在磁盘中时它也有一个明显的缺陷，那就是逻辑上相离很近但物理却可能相隔很远，这就可能造成大量的磁盘随机读写。随机读写比顺序读写慢很多，为了提升IO性能，我们需要一种能将随机操作变为顺序操作的机制，于是便有了LSM树。LSM树能让我们进行顺序写磁盘，从而大幅提升写操作，作为代价的是牺牲了一些读性能。

定义
#

LSM树是一个横跨内存和磁盘的，包含多颗"子树"的一个森林。
LSM树分为Level 0，Level 1，Level 2 … Level n 多颗子树，其中只有Level 0在内存中，其余Level 1-n在磁盘中。
内存中的Level 0子树一般采用排序树（红黑树/AVL树）、跳表或者TreeMap等这类有序的数据结构，方便后续顺序写磁盘。
磁盘中的Level 1-n子树，本质是数据排好序后顺序写到磁盘上的文件，只是叫做树而已。
每一层的子树都有一个阈值大小，达到阈值后会进行合并，合并结果写入下一层。
每一层的子树都有一个阈值大小，达到阈值后会进行合并，合并结果写入下一层。

LSM树的增删改查
#

1. 增加
#

插入比较简单，直接在level 0 树插入即可，因为level 0 树是有序的，并且level 0 树是在内存中，所以插入的速度快，时间复杂度为o(logn)，如果插入的key已经存在，那么直接转换为更新操作。

布隆过滤器

Sun, 18 Sep 2022 00:00:00 +0000

布隆过滤器
#

简介
#

本质上布隆过滤器是一种数据结构，比较巧妙的概率型数据结构（probabilistic data structure），特点是高效地插入和查询，可以用来告诉你 “某样东西一定不存在或者可能存在”。相比于传统的 List、Set、Map 等数据结构，它更高效、占用空间更少，但是缺点是其返回的结果是概率性的，而不是确切的。

HashMap
#

在讲布隆过滤器之前，我们先想有一下，判断某个元素是否存在用什么数据结构？HashMap是一个好选择，HashMap能在o(1)的时间复杂度内判断一个元素在不在，效率极高。如果数据量很小，那么HashMap确实是一个最佳选择，但是如果HashMap里存储的是上亿的key，那么他就有点力不从心了。存储上亿key的HashMap需要占用大量的空间内存，并且如果HashMap触发rehash，对那么多的key进行迁移必然会导致内存抖动。所以，HashMap并不适合存放亿级别的key。

Bloom Filter
#

前面说了HashMap不合适存放数量过多的key，那么有什么可以存放大数量的key且不会占用大量的内存？可以使用bit数组，也叫bitmap，布隆过滤器就是用bitmap来存储数据的。

如果我们要讲一个数据添加到布隆过滤器中，我们需要多个hash函数生成多个哈希值，再将这些hash值映射到对应的bit数组对的bit上，将这个bit置为1。例如针对值 “baidu” 和三个不同的哈希函数分别生成了哈希值 1、4、7，则上图转变为：

Prometheus

Tue, 16 Aug 2022 00:00:00 +0000

系统设计 on

Oauth2.0

cat Oauth2.0 #

简介 #

运用场景 #

授权流程 #

准备工作 #

熔断与限流

微服务限流 #

1. 固定窗口算法 #

一致性哈希

一致性hash #

如何分配请求 #

普通哈希 #

一致性哈希 #

web安全

web安全 #

1. CSRF攻击 #

a. CSRF的基本攻击原理 #

b. CSRF的防范 #

GeoHash算法

GeoHash #

背景 #

GeoHash #

编码规则 #

编码示例 #

设计模式之简介

设计模式 #

简介 #

分类 #

原则 #

延迟队列

延迟队列 #

定义 #

应用场景 #

如何实现 #

1. Redis的Zset #

分布式理论

分布式理论 #

CAP理论 #

BASE理论 #

Raft协议 #

DDD领域驱动设计

领域驱动设计 #

1.分层架构 #

2. todo… #

设计模式之行为型模式

行为型模式 #

1.模版方法模式 #

缓存策略

缓存策略 #

1. 双写策略 #

a. 先更新数据库，再更新缓存 #

b. 先更新缓存，再更新数据库 #

设计模式之创建型模式

创建型模式 #

1.单例模式 #

幂等设计

幂等设计 #

什么是幂等？ #

如何保证幂等？ #

1. insert前先select #

2. 悲观锁 #

设计模式之结构型模式

结构型模式 #

1.代理模式 #

分布式ID

分布式ID #

1. 什么是分布式ID #

2. 如何生成分布式ID #

a. uuid #

LSM树

LSM树 #

简介 #

定义 #

LSM树的增删改查 #

1. 增加 #

布隆过滤器

布隆过滤器 #

简介 #

cat Oauth2.0
#

简介
#

运用场景
#

授权流程
#

准备工作
#

微服务限流
#

1. 固定窗口算法
#

一致性hash
#

如何分配请求
#

普通哈希
#

一致性哈希
#

web安全
#

1. CSRF攻击
#

a. CSRF的基本攻击原理
#

b. CSRF的防范
#

GeoHash
#

背景
#

GeoHash
#

编码规则
#

编码示例
#

设计模式
#

简介
#

分类
#

原则
#

延迟队列
#

定义
#

应用场景
#

如何实现
#

1. Redis的Zset
#

分布式理论
#

CAP理论
#

BASE理论
#

Raft协议
#

领域驱动设计
#

1.分层架构
#

2. todo…
#

行为型模式
#

1.模版方法模式
#

缓存策略
#

1. 双写策略
#

a. 先更新数据库，再更新缓存
#

b. 先更新缓存，再更新数据库
#

创建型模式
#

1.单例模式
#

幂等设计
#

什么是幂等？
#

如何保证幂等？
#

1. insert前先select
#

2. 悲观锁
#

结构型模式
#

1.代理模式
#

分布式ID
#

1. 什么是分布式ID
#

2. 如何生成分布式ID
#

a. uuid
#

LSM树
#

简介
#

定义
#

LSM树的增删改查
#

1. 增加
#

布隆过滤器
#

简介
#

HashMap
#

Bloom Filter
#