mit6.824

lab1 已经完工,但是遵循

Collaboration Policy

Please do not publish your code or make it available to current or future 6.824 students. github.com repositories are public by default, so please don’t put your code there unless you make the repository private. You may find it convenient to use MIT’s GitHub, but be sure to create a private repository.

所以我的代码就不开源了,所有的笔记我会在学习完所有课程,做完四个 lab 后整理后开源。

upd: 做完第一个 mapreduce 后就没时间做其他的了…

浅析分布式唯一ID生成算法——snowflake的实现

开头先放一个snowflake的实现——仓库地址

分布式唯一Id是什么

分布式唯一Id其实是一个分布式系统里面的一个不可或缺的元素,他一般具有如下几个特性

  • 同一业务的全局唯一性(globally unique)
  • 包含时间信息(timestamp)
  • 递增有序性(incremented and ordered)

分布式唯一Id有什么用

这样一个分布式唯一Id,在一个分布式系统中的作用都有些什么呢。

举个例子,比如说业务量大了要做分库分表了,拿MyCat这个中间件举例,你对接了MyCat这个中间件后,你是接触不到MyCat后面被取余策略或其他策略分离的表的。MyCat呈现给你的仍然是一张表,但是却是分离的表的合并。 那这个时候你后面的数据库的主键要是还是和单机的策略一样,仍然是普通的auto_increment 1的话,你的分割后的每张表都会有重复的Id。
比如说有一组订单表order_1, order_2

无状态服务,有状态服务与CAP定理

运维的一些职责

  • 安全
  • 稳定
  • 满负荷
  • 长周期
  • 优于拓展

无状态服务

无状态服务包括api服务,订单服务,购物车服务,图片服务,消息队列服务,负载均衡服务。无状态服务指的是,在整个系统运行过程中,在任意时刻,你将他销毁并重新创建一个全新的这种服务,他仍然可以完整的进行之前的工作。
这就意味着同一个无状态服务是可以分到不同的计算节点上的。比如说我们可以创建十个API服务,当外部服务请求这个API的时候,我们需要使用反向代理技术(Nginx),将这些用户请求都代理给负载均衡,负载均衡通过负载均衡算法,例如源地址hash,cookie,或者轮转法来讲这些请求分配给一个随机的计算节点,这样这10个计算节点压力都不会太大!这其实就是经典的无状态服务负载均衡的部署方式,也是运维的满负荷职责体现!而随着服务开的越来越多,服务占用的计算资源也越来越多。那又如何实现优于拓展呢?我们可以在请求量大的时候,将我们的服务缩放到更多的服务,而业务量小的时候,就压缩回一个服务,在这个过程中,我们需要删除或增加大量的计算节点,这会非常麻烦,使用传统的物理机几乎是不可能的,而使用虚拟机事实上也是又非常浪费内存资源。其实最近几年诞生的一些新的技术,比如说容器,kubernetes,他们其实就有这种功能,他们可以根据业务量计算需求自动的缩放你的无状态服务数量。其实这个还涉及到健康监视的内容。这里不细写,因为我自己也不是很了解。

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×