Monthly Archives: August 2022

1 计算性能预估 发微博 日活2.5亿，平均每人日发一条，共2.5亿条。60%集中在四个小时发送，平均TPS 为： 2.5 亿*0.6/(3600*4) =10K/s 看微博 平均一条微博100次观看，且活跃时间与发微博相同。平均QPS为： 10K/s*100 = 1000K/s 发评论 平均一条微博5条评论，且活跃时间与发微博相同。平均TPS为： 10K/s*5= 50K/s 看评论 平均一条微博评论10次观看，且活跃时间与发微博相同。平均QPS为： 50K/s*10=500K/s 2 高性能计算架构 业务特性分析 发评论是写操作，因此不能用缓存，可以用负载均衡。实时性要求不高，可以考虑用消息队列进行缓冲。 看评论是读操作，由于发了评论不能修改，适合用缓存架构。由于请求量大，负载均衡也需要。 架构分析 负载均衡的算法： 发评论和看评论在任何服务器上都可以，简单选择“轮询”或者“随机”算法。 看评论缓存： 采用与看微博类似的CDN能承载90%的用户流量。使得看评论的QPS只有10%，也就是50K/s进入系统。 业务服务器数量估算： 发评论与发微博类似，涉及内容审核，数据写入存储，数据写入缓存，因此按照一个服务器每秒处理500来估算，完成50K/s的TPS，需要100台服务器，加上一定的预留量，120台服务器差不多了。 看评论除去CDN的流量，50K/s进入系统。由于读评论逻辑简单，主要是读缓存系统，假设单台服务器处理能力是1000/s，机器数量为50台，加上20%的预留量，60台服务器差不多了。 架构设计 4级负载均衡架构 缓存采用多级缓存架构，包括APP/浏览器缓存，CDN缓存，WEB容器缓存，进程内缓存，分布式缓存。 由于评论发了之后不能更改，以及时间局部性，进程内缓存不会造成一致性的问题，并且可以大大降低对于数据库，文件/对象存储的读取请求。 3 高可用计算架构 架构设计分析 … Continue reading →

存储性能估算 假设每门课2次考试，每个学生每学期20门课。 在校学生：1000万 * 20（门） *2（次） *1000（Byte/考试） *2（学期） *3（年） = 2.4T 离校学生：每年250万，存储量 0.6T 假设学校考试都在一个月内，考试集中在上午4小时和下午4小时。请求试卷集中在考试前的一分钟，提交答案集中在考试开始前的一分钟，提交答案集中在考试结束前30分钟。 请求试卷：1000万 * 20（课）/20（天）/4（次考试）/1分钟 = 5万/秒 提交试卷： 5万/30分钟 = 1700/秒 数据结构设计 采用Redis sentinel来存储试卷。 技术本质： In memory Key value store，高性能。 主从复制，读写分离。 Master 故障时， sentinel自动切换。 试卷读取的数据结构： Key：采用学校ID + 课程ID … Continue reading →

前言 1. 业务背景 本文是外包学生管理系统详细架构设计文档，用于指导学生管理系统的开发，测试和运维。 基于学生数量和需要管理的数据的增加，线上管理系统成为必要。该系统将要解决的问题有： 存储和维护学生，课程及考试等相关信息。 提供学生，教师以及管理人员的注册，登陆和信息查询功能。 提供学生，教师以及管理人员基于角色的访问和修改权限。 2. 约束和限制 开发时长：两个月之内 开发语言：JAVA 数据库：MySQL数据库 硬件费用：十万元/年 高性能：支持1000学生同时在线 可用性：访问高可用达到99%；存储信息要高可用 安全性：防止信息泄漏，篡改，丢失 3. 总体架构 3.1 架构分析 高性能：学生数目约为一千，对于高性能，高并发的要求不高。 高可用：可以容忍1%系统维护而造成的宕机；数据要尽量保证高可用不丢失，因为缺失信息的补全比较麻烦。最好能定期做备份，降低关键数据丢失的可能性。 可扩展：系统的要求基本固定，可以不考虑扩展 安全性：保证信息安全；尽量避免泄漏，篡改，丢失 3.2 总体架构 网关和负载均衡：采用Nginx做简单的负载均衡，满足1000学生的并发访问；并能依据http请求的类别，访问不同的子系统 后端服务：后端服务拆分为学生子系统，课程考试子系统 以及权限子系统三个子系统。承载了Nginx的访问请求，并能访问MySQL数据库和文件服务器。 数据存储：采用一主一备的MySQL服务器和文件服务器，分别存储结构化和非结构化的信息。 4. 详细设计 4.1 核心功能 4.1.1 学生的注册登陆 4.1.2 学生选课 4.1.3成绩录入 … Continue reading →