面向加薪学习

哨兵之前我们主从架构中，如果主节点挂了，我们要人为干预。现在 Redis 引入了哨兵这个机制，自动化故障恢复。 下图，右面是数据节点，左面是哨兵，它是分布式架构模式，主要就是监控数据节点的主从服务器，自动切换故障节点。 概念 监控(Monitor)：哨兵会不断检查主从节点运作正常。 通知（Notification）：如果有问题，那么会通过 api 发送消息出去。 故障自动迁移(Automatic failover)：当一个主服务器故障，哨兵会自动发生故障迁移。 配置提供者（Configuration provider）客户端不需要直接链接到主从节点，可以直接连接到哨兵，因为哨兵提供了一个服务发现的功能，客户端连接到哨兵后，就可以获取到主从节点的信息，如果主节点发生故障，重新产生主节点，哨兵也会把新的信息同步给客户端。 哨兵的分布式好处可以再一个架构中运行多个哨兵进程。 降低误报。（决策机制，大多数节点认为正确的事情，才是正确的） 减低客户端的影响。（哨兵可以统一的对外提供服务，并不用关心数据节点内部细节） 任意哨兵都可以对外提供服务。 哨兵模式基于主从模式，所有的优点，哨兵都有。 ...

主从复制 + 读写分离先回顾上一章我们学习的单点服务。 redis 单节点部署优点: 成本低（服务器少） 部署简单（就一个单节点） 性能高（单机不需要同步数据，天然数据一致性） 缺点 单点故障（可靠性很差） CPU 处理能力受限（Redis 是单线程的） 主从复制 图上 3 个客户端都是读写主节点。假设，当流量小的时候，我们这个主节点完全可以满足业务需求，但是由于业务扩大，流量增加，redis 压力增大，其主要压力都是读，写的压力不大，所以一个节点写，问题也不大，扩展从节点就可以应对。 优点: 职责分明，读和写各司其职 扩展性好，加机器就可以。 故障恢复如果上面的主节点宕机，可以手动把上面的一个从节点升级成主节点（后面会介绍哨兵，解决 手动切换的问题） 缺点 数据冗余，每个从节点都会有相同容量的数据。（后面讲集群分片，解决这个问题） 数据压力大，现在每个从节点都是全量复制主节点数据。如果 1 个主节点，过多的从节点也会造成数据同步压力。 我们单独看，发现 Master 是单点，如果宕机，就不能提供写数据能力了。（后面讲集群分片，解决这个问题） 搭建环境 1 主 2 ...

互联网用户登录模式变迁史(三)JWT 是什么JWT(JSON Web Token)是一个开放标准(RFC 7519)，它是自包含的方式，用于作为 JSON 对象在各方之间安全地传输信息。该信息可以被验证和信任，因为它是数字签名的。 JWT 长什么样 Header 由两部分组成：token 的类型（“JWT”）和算法名称（比如：HMAC SHA256 或者 RSA 等等） Payload 它包含实体和数据的声明。声明有三种类型： registered claims: 不是强制的，只是推荐。比如: iss(jwt 签发者)，exp（jwt 的过期时间）,sub(jwt 所面向的用户)，aud(接收 jwt 的一方),iat(jwt 的签发时间)等。 public claims:可以随意定义。 private claims:用于在同意使用他们的各方之间共享信息，并且不是注册或公开的声明。 注：不要在 Payload 中放置敏感消息 签名(Signature) 通过下面的公式得到签名。用于验证消息在传递过程中是否被篡改，如果使用私钥的 token，还可以验证 JWT 的发送方是否为它 ...

互联网用户登录模式变迁史(二)我们先看一下现实中的例子，出去旅游（预计 3 天），肯定要订酒店，我们出示订单和手机号，酒店前台验证通过后，就可以给我们房卡，但是，房卡是有时间期限的（3 天），3 天内，我们回房间是不用再去前台登记了，直接进入房间。但是过了 3 天，这个房卡就失效了，除非我们继续和酒店续签。这和我们要说的 Oauth2.0 很相似。 这个案例里面有 3 个角色: 我（自己） 用户 酒店前台 授权中心 房间 资源 下面我们看一下 Oauth2.0 的运行流程，如下 A—客户端向认证授权服务器请求 Access Token。 B—授权服务器验证通过，签发 Access Token 过期属性等，还有 Refresh Token。 C—携带 Access Token 访问资源服务器。 D—资源服务器验证 Access Token,通过后，返回请求内容。 E—执行 C 和 D,如果验证不通过，则执行 F 步骤。 G—当 Access Token 过期的时候，那么携带 Refresh Token。这样无需用户再次登录。 H—如果执行 G 步骤，成功的话，那么就返回 Acce ...

互联网用户登录模式变迁史(一)单体架构在单体服务的时候，登录和注册是很常见的一个功能。 大家都知道，HTTP 是无状态的协议，那么服务器无法确认用户的信息，也就是说服务器不知道客户端谁是谁，这个问题难不倒聪明的人类，W3C 就提出了：给每一个用户都发一个通行证，无论谁访问的时候都需要携带通行证，这样服务器就可以从通行证上确认用户的信息。通行证就是Cookie。 只有客户端带着通行证Cookie，服务器也是一脸蒙啊，于是服务器就使用Session,服务器向用户浏览器发送了一个 SESSION_ID 的 Cookie，它的值是 Session 的 id 值。其实 Session 是依据 Cookie 来识别是否是同一个用户。 也就是说，服务器和每个客户端会建立一个 session,然后返回这个 session 的 id,当做 Cookie,当用户使用浏览器再次请求服务器的时候，服务器会检查这个 cookie，也就是会去服务器查找是否存在这个 session 的 Id。Session 本身也需要配合 cookie 来使用的。 所以，一般我们单体服务系统实现登录会这样做： 登录：将用户信息保 ...

技术栈rust、diesel、actix-web、postgresql01.Rust 实战-环境搭建 02.Rust 实战-错误处理 03.Rust 实战-数据库相关 04.Rust 实战-Employee 操作 05.Rust 实战-API 操作 06.Rust 实战-main 函数 07.Rust 实战-Rest 接口测试 添加微信 公众号更多内容

Async/Await为什么在 39 节介绍了闭包相关内容?因为在大多数情况下，无论是使用 futures 还是 async/await 实现 std::future::Future trait 都只是另一个包装闭包的结构！ 下面写 2 个普通函数 12345678910111213141516171819fn do3() { for i in 1..=5 { println!("do3 {}", i); sleep(Duration::from_millis(500)); }}fn do4() { for i in 1..=5 { println!("do4 {}", i); sleep(Duration::from_millis(1000)); }}fn main() { do3(); do4();
...

闭包的使用2019 年 11 月，Rust 1.39.0 中 async-await 的发布增加了它作为现代系统编程语言的吸引力，并使其更容易编写高度并发的服务。 现在要完全理解和理解 async-await 是如何产生的，如何使用它。我们看一下如何演进出来的。 新建项目 1cargo new use_closuer39 打开 src/main.rs 123let add = |x, y| x + y;let result = add(3, 4);println!("{}", result); 这是一个闭包。并且调用了它，会打印出结果是 7 如果闭包可以像普通函数一样被调用，那我们该如何使用呢？ 123456789101112131415fn receives_closure<F>(closure: F) where F: Fn(i32, i32) -> i32,{ let result = closure(3, 5); println!("闭包作为参数执行结果 ...

AOF vs RDB 对比redis 是一个内存型数据库，之前在《Go 语言+Redis 实战课》中签到的案例，数据是放到 redis 中，还有秒杀的案例，部分数据也是放到了 redis 中，如果这个时候，redis 故障了，redis 重新启动以后，内存中的数据肯定就全部消失了，用户是抱怨的，老板肯定也是不接受的。那 Redis 也提供了数据持久化到磁盘上的能力，就可以避免数据丢失了。 Redis 提供了两种方式保存数据数据的方式: RDB AOF 面试知识点梳理RDB 要学什么？ 什么是持久化，什么是快照？RDB 的工作原理以及优点和缺点是什么？ AOF 要学什么？ 为什么要有 AOF? 如何选择 RDB 和 AOF,如何互补？ 单独开启 RDB?单独开启 AOF? 还是 2 个一起开始，那 2 个都开启，数据冗余怎么考虑？ AOF 存储的是一个文件，这个文件有上限吗？ 存储上限到了，怎么办？ 要重写，为什么要重写？ 重写的触发条件是什么？ 常用的配置是什么？ 文件如何写入？文件损坏了，怎么办？ redis 在运行中，开启的是 rdb,在 redis 不重启的情况下，数据不丢失 ...

Redis 分区分区是分割数据到多个 Redis 实例中去，分区后，每个 Redis 实例只保存 key 的一个子集（一部分）。 分区的好处 通过利用多台计算机内存，可以存储更多的数据。 通过多核和多台计算机，提供更高的性能。 通过多台计算机和网络适配器，提供更强的传输能力。 分区的劣势 不支持多个 Key 的操作。 不支持多个 key 的事务操作。 分区后，处理数据变得复杂（要处理不同机器上的 rdb/aof 文件）。 分区类型 范围分区，是最简单的分区方式，比如从 id 1 到 100 的订单保存到分区 1,101 到 200 的订单保存到分区 2。不足是每增加区间范围都要维护一个映射表，要记得，哪个分区和哪个范围有联系。 哈希分区，比范围分区更好的方法，可以对任何 key 都适用，key 不需要是 object_name:这样的形式。 Hash(key),用 hash 函数对 key 进行计算出一个整数。 对这个整数取模操作得到一个数值。 将上一步的结果映射到对应的实例中。 比如我们分区是 16 个，我们算出来的 hash 数值是 83084917 1 ...