系统设计问题

1 题外话和系统设计无关的

内存映射问题

一个进程虚拟地址 2^64/2^32 (64和32取决于计算机多少位)，虚拟地址里面分段，每段里面分页
每个进程都只知道自己存在，以为自己是计算机唯一存在的

逻辑地址 假设20 -> 线性地址-> 1000(段基地址) + 20(偏移量) -> 物理地址 (LRU分页替换等)

C

预处理 -> 汇编 -> 链接 -> 生成可执行代码(二进制)

这个编译器教学讲得是我看到的最好的，就是有点长，大二的时候看了两遍，现在都忘差不多了

2 单点登录问题

为什么会有单点登录问题？
	 不同页面登录一个，其他页面自动登录

以前用session解决单点登录问题，在现在Nginx集群下不行了。衍生出3种解决方法
	1 iphash
		Nginx下 ip绑定一个服务器，以后所有这个ip请求都只走同一个服务器
	2 同步session
		但是有网路延迟，并发不能太高。不同的微服务下，不在同一集群，session无法同步
	3 redis/第三方缓存 (主流，百分之90使用)
		1 user 登录淘宝时，会put Map<key: 唯一值如UUID，value: user信息>到redis
		2 put完后把key值返回user (cookie/localstore/session)
		3 user 再次登录天猫时候，通过(cookie/localstore/session)拿到key直接登录

3 第三方登录问题

	通过QQ登录百度网盘
	1 user发送请求到百度网盘 (通过QQ登录，但是百度网盘不能知道QQ信息)
	2 百度网盘重定向，引导用户到QQ登录页面
	3 QQ校验账号密码，状态码callback，状态码只用一次，有效期很短，只能callback地址用
	4 QQ响应状态码给callback地址给百度网盘
	5 百度网盘用状态码去换取token (token能存和加密user信息，有有效期)
	6 QQ返回token给百度网盘

4 SSL非对称加密

起初是对称加密，交易双方都使用同样钥匙，安全性得不到保证，所以非对称加密诞生了

一个服务器通过公钥加密再通过私钥解密。公钥是依赖于私钥，通过私钥生成

1 发送数据时： 数据+加密算法，被拦截下因为没有解密算法无法获得数据
2 直接发送私钥解密会数据泄露，所以需要第三方CA机构认证(收集企业信息，域名，公钥)
3 客服端生成随机数，利用CA公钥再次加密。服务器拿私钥解密拿到随机数，双方利用该随机数作为钥匙进行以后通讯

5 设计高并发系统架构

设计高并发主要为了降低TPS/QPS问题。最重要的要首先在上层能够承受请求，然后再设计处理请求

地域上负载均衡：DNS
硬件上负载均衡：F5 集群之间负载均衡
软件上负载均衡：LVS，Nginx主机之间负载均衡
DNS，F5不是重点略过了

缓冲，缓存，复用，分治，亲密粘性，负载均衡

降低QPS，可以一次请求多个css而不是一个css，可以使用雪碧图(一个大图包含多个小图然后css切割小块使用)

1 第一层LVS集群承受10万+QPS压力，承受流量压力。
使用LVS服务端负载均衡，keepalived集群LVS
LVS用来承受流量压力，Nignx层拿握手，后面再应用计算

为什么LVS性能高到能承受第一轮海量并发，而不是使用Nginx？
	LVS在传输层，Ngnix在应用层。LVS没有应用层的额外开销，性能大大提升
	LVS在传输层，负载均衡服务器，数据包转发级别，不需要和客户端三次握手
	Nginx在应用层有会话，上下文，http的response，require等额外开销

LVS具体原理

局域网内会通过NAT路由器，转换IP地址的交换机
LVS原理类似NAT交换机，有三种IP交换实现策略
	1 VS/DR (Virtual Server vs Direct ROuting)
	通过改写MAC地址，将请求发到真实服务器上，直接相应客户，不再需要IP隧道的开销。但要求调度器和真实服务器都有一块网卡连在同一物理网段上

	2 VS/NAT 
	调度器重写请求报文目标地址，通过调度算法请求发送到真实服务器上。服务器响应后通过调度器，再次重写报文源地址返回客户

	3 VS/TUN
	使用NAT时，请求和响应都要调度器重写，当请求太大时，调度器承受不了，所以调度器把请求报文通过IP隧道发送到真实服务器响应。所以调度器只处理请求报文，集群吞吐量上升10倍。

2 CDN和FastDFS

FastDFS集群保存静态文件
	FastDFS开源轻量级分布式文件系统
	Tracker跟踪器类似HDFS的NameNode，storage储存节点类似HDFS的DataNode
	FastDFS和HDFS区别，FastDFS存文件不是云计算，只面向文件上传和下载
	HDFS我在之前文章专门写过
CDN从FastDFS中拉取数据
	内容分发网络
	使用户就近获取所需要的内容，减少网络阻塞，提高访问响应
	CDN依靠部署在各地边缘服务器，包括中心平台负载均衡，内容分发，调度等功能模块
	比如下载Jquery库，通过CDN分析从就近节点上快速下载下来

3 第二层Nginx集群网关层承受1万QPS压力，承受三次握手压力

相比较Apache，Apache稳定成熟，轻量级，占内存少，一个请求一个进程同步阻塞。
Nginx异步非阻塞，多个请求对应一个进程，社区活跃

在Nginx集群层：本地缓存(存静态页面)，动静分离(静态页面直接读Nginx)，反向代理，负载均衡

4 微服务架构业务网关层

微服务和SOA区别？ -> SOA服务偏业务划分，微服务功能服务划分，微服务比SOA更细腻
如SpringCloud下Zuul网关组件
	zuul 网关，整体管理
		http超时，routes path xxx下都走该网关等
	处理权限系统和单点登录

	Eureka(concurrentHashMap<String,Lease~心跳续约对象(注册信息，过期时间等)>)/zookeeper
	Feign/Dubbo 远程调用RPC
		Feign：
		一端
		@FeignClient(name="yunyun")
		public interface yunyun{}
		
		另一端
		@Autowired
		yunyun yun;
		~create(){
			直接调用yun下的方法
		}
	Ribbon 客户端负载均衡
	hystrix 容错-限流，熔断，降级
	Stream 消息驱动 (如中间加MQ解耦)
	View渲染(JSON,FreeMarker等)

5 额外具体业务层削峰

一些思路举例
	1 熔断
	2 降级
		前端层面：使用本地缓存，使用假数据，JS访问不到直接不发送数据，静态化降级
		后端层面：平时Redis+DB，高峰时Redis+kafka等消息队列削峰+DB
	3 限流
		 压测计算每秒请求消耗时间，桶令牌限流，
	4 每个业务层级AKF设计+主从+集群
	5 通过redis等缓存，请求不轻易走到数据库层面
	6 循环阑珊，倒计数器等多线程处理业务
	7 Hadoop分布式并行加快处理业务速度等