系统设计
文章平均质量分 88
大型商用系统的设计原理 和 设计示例
喜欢迈巴赫的将军
忠橙
展开
-
系统设计实例(四)日活5000万的聊天系统
当用户A的在线状态发生变化时,它将事件发布到所有的通道,朋友们很容易获得在线状态的更新,对于小用户群体是有效的。它注册所有可用的聊天服务器,并根据预定的标准为客户端选择最好的聊天服务器。如果状态服务器在一定时间内,比如从客户端开始的x秒内,接收到一个心跳事件,用户就被认为是在线的。每个设备都维护了一个名为cur_max_message_id的变量,该变量跟踪设备上最新的消息ID。由于每个设备上的cur_max_message_id都不同,每个设备都可以从KV存储中获取新消息,因此消息同步很容易。原创 2024-03-24 12:04:53 · 792 阅读 · 0 评论 -
系统设计实例(三)Youtube视频分享平台
一旦相应的视频处理完成,临时存储中的数据就会被清理掉。为了支持不同的视频处理流程并保持高并行性,重要的是增加一些抽象层次,并让客户端程序员定义要执行的任务。美国的人可以将视频上传到北美的上传中心,中国的人可以将视频上传到亚洲的上传中心。它是将视频格式转换为其他格式(如MPEG,HLS等)的过程,这些格式为不同的设备和带宽能力提供最佳的视频流。客户端向API服务器发起HTTP请求,以获取预签名URL,该URL给予访问URL中标识的对象的访问权限。元数据缓存:为了更好的性能,视频元数据和用户对象被缓存。原创 2024-03-22 17:26:02 · 727 阅读 · 0 评论 -
系统设计实例(二)新闻订阅系统
*混合扩散:**由于快速获取新闻订阅很关键,所以我们对大部分用户使用推送模型。对于那些有许多朋友/粉丝的名人或用户,我们让粉丝按需拉取新闻内容,以避免系统过载。扩散是将帖子传递给所有朋友的过程。有两种类型的扩散模型:写时扩散(也称为推送模型)和读时扩散(也称为拉取模型)。登录的用户才能发布帖子。系统限制用户在一定时间内可以发布的帖子数量,这对于防止垃圾邮件和恶意内容至关重要。:在这种方法中,新闻订阅在写入时预先计算。在读取时生成新闻订阅,这是一个按需模型。用户加载主页时,会拉取最近的帖子。原创 2024-03-21 20:43:12 · 620 阅读 · 0 评论 -
系统设计实例(一)百万级别用户系统
有状态Web层的问题在于同一客户端的每个请求必须路由到同一台服务器,我们将状态(例如用户会话数据)从Web层中移出,做法是将会话数据存储在持久性存储中,如关系型数据库或NoSQL数据库。用户的HTTP请求可以发送到任何Web服务器,这些服务器从共享数据存储中获取状态数据。它们从 CDN 获取以获得更好的性能。负载均衡器会将传入的流量均匀分配给在负载均衡集合中定义的Web服务器,用户直接连接负载均衡器的公共IP。在正常运行时,用户会根据地理位置通过geoDNS路由到最近的数据中心,其中在美国东部的流量占。原创 2024-03-20 23:02:21 · 1020 阅读 · 0 评论 -
RESTful API学习
对资源的操作包括获取、创建、修改和删除,这些操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。:服务器不能保存客户端的信息, 每一次从客户端发送的请求中,要包含所有必须的状态信息,会话信息由客户端保存, 服务器端根据这些状态信息来处理请求。它主要用于客户端和服务器交互类的软件。:资源可以是一个图片、音乐、一个XML格式、HTML格式或者JSON格式等网络上的一个实体,除了一些二进制的资源外普通的文本资源更多以JSON为载体、面向用户的一组数据(通常从数据库中查询而得到)。原创 2024-03-10 19:58:29 · 493 阅读 · 0 评论 -
系统设计学习(五)微服务
所有的微服务都是独立的Java进程跑在独立的虚拟机上,所以服务间的通信就是IPC(inter process communication),已经有很多成熟的方案。另外,每个服务都有自己的缓存和数据库。缺点是客户端要维护所有调用服务的地址,有技术难度,一般大公司都有成熟的内部框架支持,比如Dubbo。最重要的作 用是为前台(通常是移动应用)提供后台服务的聚合,提供一个统一的服务出口,解除他们之间的耦合。缺点:多服务运维难度,系统部署依赖,服务间通信成本,数据一致性,系统集成测试,重复工作,性能监控等。原创 2024-03-17 21:59:28 · 476 阅读 · 0 评论 -
系统设计学习(四)海量数据
海量日志数据,提取出某日访问百度次数最多的那个IP,如果想一次性把所有IP数据装进内存处理,则内存容量明显不够,故针对数据太大,内存受限的情况,可以把大文件转化成(取模映射)小文件,从而大而化小,逐个处理。注:Hash取模是一种等价映射,不会存在同一个元素分散到不同小文件中去的情况,即这里采用的是%1000算法,那么同一个IP在hash后,只可能落在同一个文件中,不可能被分散的。同样的,有一个1G大小的一个文件,里面每一行是一个词,词的大小不超过16字节,内存限制大小是1M。返回频数最高的100个词。原创 2024-03-15 18:47:24 · 1012 阅读 · 0 评论 -
系统设计学习(三)限流与零拷贝
水流进桶的速度可以是随机的,但是水流出桶的速度是恒定的。当水流进桶的速度过快时,桶会逐渐被填满,当水超过桶的容量就会溢出,即被丢弃。如果桶中没有足够的令牌,请求就会被阻塞或丢弃,具体行为取决于具体的实现。如果在这个时间窗口内的请求已经达到了限制,那么新的请求就会被拒绝,过了当前时间窗口后,会进入下一个时间窗口,并重置窗口内的请求数量,重新计算。在固定窗口限流算法中,如果大量请求在一个时间窗口的边界附近到达,可能会造成瞬时的流量突增。滑动窗口随着时间的推移,动态统计请求量,避免了在窗口边界附近的流量突增。原创 2024-03-13 17:07:13 · 907 阅读 · 0 评论 -
系统设计学习(二)用户认证场景
我们知道http代理客户端不只有浏览器,还有原生APP等等,这个时候cookie是不起作用的,使用token时,客户端在收到响应的时候,可以把他存在本地的cookie,storage,或者内存中,然后再下一次请求的请求头重带上这个token就行了。认证中心和其他系统是在一个域名下的,认证中心为父域名(jwxt.com),其他系统是子域名(yx.jwxt.com),或者是同一IP不同端口的情况,我们的服务端通过cookie去判断是否登录。在认证中心登录成功的时候设置Cookie,原创 2024-03-12 19:51:12 · 1004 阅读 · 0 评论 -
系统设计学习(一)分布式系统
CAP 理论指出,在分布式系统中,不能同时满足一致性、可用性和分区容错性这三个特性,只能是 CP 或者是 AP(在分布式系统中,分区是无法避免的,当分区发生时,我们必须在一致性和可用性之间做出选择)。索引:是日志条目在日志中的位置,表征了特定日志条目在整个日志序列中的顺序。(2)如果在不同日志中的两个条目有着相同索引和任期号,则它们之间所有条目完全一样,这点是由日志复制的规则来保证的;(1)如果在不同日志中的两个条目有着相同索引和任期号,则所存储的命令是相同的,这点是由leader来保证的;原创 2024-03-11 22:43:50 · 1008 阅读 · 0 评论