weititer0000
一个汉字
gbk 两个字节
utf-16 两个字节
utf-8编码 3个字节
用户主机>本地dns（将浏览器发送的url(域名)解析成目标服务器ip）>浏览器向指定服务器请求服务。
有cdn:
浏览器>dns将解析操作移交给cdn>cdn向服务器发送负载均衡设备ip>浏览器>负载均衡设备ip>浏览器得到缓存服务器ip>缓存服务器向目标服务器发送请求>目标服务器将数据发给缓存服务器>缓存服务器将数据发给浏览器>浏览器
说明：cdn服务器和应用服务器、负载均衡服务器、反向代理服务器，都是需要开发团队自己维护。方向代理服务器。除了可以转发请求，还可以检查请求需要的内容是否缓存于服务器中，若存在，则此次请求是结束了。
缓存命中：这条数据在缓存中存在，可以返回。
缓存未命中：这条数据存在缓存中，这条数据因为太久没有使用被淘汰。这样吧，缓存中存在这条数据，所以这条数据可以写到缓存中。
如何避免数据库负载压力太大？
1、有100w关注者的用户发布微博时，将数据写入应用服务器的本地缓存中，少于100w
关注者的用户，将微博写入redis服务器，当然无论是哪个用户发布的微博都会在消息队列服务器中被消费而写入mysql。读的时候，先从应用服务器中读取（100w关注者的用户），没有就从redis服务器中读，条数不满20条，从mysql中读。
2、限制每个用户发布微博的条数为50条。
如何快速响应用户请求？
1、从应用服务器中读被获取次数超过100w次的微博（有100w个关注者，意味着好有刷微博的时候，会查询一次大博主发布的微博，而有100w个人要刷）。
2、好友比较少的用户发布的微博就存在redis服务器中，不满20条就从mysql中查一下，由于lru算法，这名用户发布的微博有极大可能会因为哈希链表长度满而被淘汰掉。每次读一次微博，微博的查看时间会被更新一次，缓存中没有的微博会加到链表第一位，缓存命中的微博，也会被从当前节点更新到链表首位，而很少被命中的微博会随着长度的限制，从链表中被去除。
10 万 QPS 的 并发量如何应对？
1、尽量用缓存，而不是查询mysql。高性能特点。使用lru算法。缓存中不足20条的才查询mysql。