获得徽章 1
#青训营笔记创作活动# 2月9日 打卡day10
秒杀系统的9个细节:
瞬时高并发
页面静态化
秒杀按钮
读多写少
缓存问题
库存问题
分布式锁
mq异步处理
如何限流
展开
评论
#青训营笔记创作活动# 2月8日 打卡day9
Redis高性能的原因
1.完全基于内存
2.数据结构简单,操作方便,并且不同数据结构能够应对于不同场景
3.采用单线程(网络请求模块使用单线程,其他模块仍用了多线程),避免了不必要的上下文切换和竞争条件,也不存在多进程或多线程切换导致CPU消耗,不需要考虑各种锁的问题。
4.使用多路I/O复用模型,为非阻塞I/O
5.Redis 本身设定了 VM 机制,没有使用 OS 的Swap,可以实现冷热数据分离,避免因为内存不足而造成访问速度下降的问题
展开
评论
#青训营笔记创作活动# 2月7日 打卡day8
UDP就一定比TCP快吗?
TCP为了实现可靠性,引入了重传机制、流量控制、滑动窗口、拥塞控制、分段以及乱序重排机制。而UDP则没有实现,因此一般来说TCP比UDP快。
TCP是面向连接的协议,而UDP是无连接的协议。这里的"连接"其实是,操作系统内核在两端代码里维护的一套复杂状态机。
大部分项目,会在基于UDP的基础上,模仿TCP,实现不同程度的可靠性机制。比如王者农药用的KCP其实就在基于UDP在应用层里实现了一套重传机制。
对于UDP+重传的场景,如果要传超大数据包,并且没有实现分段机制的话,那数据就会在IP层分片,一旦丢包,那就需要重传整个超大数据包。而TCP则不需要考虑这个,内部会自动分段,丢包重传分段就行了。这种场景下,其实TCP更快。
展开
评论
#青训营笔记创作活动# 2月6日 打卡day7
Kafka基本知识
整个 Kafka 体系结构中引入了以下 3 个术语。
Producer:生产者,也就是发送消息的一方。生产者负责创建消息,然后将其投递到 Kafka 中。
Consumer:消费者,也就是接收消息的一方。消费者连接到 Kafka 上并接收消息,进 而进行相应的业务逻辑处理。
Broker:服务代理节点。对于 Kafka 而言,Broker 可以简单地看作一个独立的 Kafka 服务节点或 Kafka 服务实例。大多数情况下也可以将 Broker 看作一台 Kafka 服务器,前提是这台服务器上只部署了一个 Kafka 实例。一个或多个 Broker 组成了一个 Kafka 集群。一般而言, 我们更习惯使用首字母小写的 broker 来表示服务代理节点。
展开
评论
#青训营笔记创作活动# 2月5日 打卡day6
websocket协议:TCP协议本身是全双工的,但我们最常用的HTTP1.1,虽然是基于TCP的协议,但它是半双工的,对于大部分需要服务器主动推送数据到客户端的场景,都不太友好,因此我们需要使用支持全双工的websocket协议。
在HTTP1.1里。只要客户端不问,服务端就不答。基于这样的特点,对于登录页面这样的简单场景,可以使用定时轮询或者长轮询的方式实现服务器推送(comet)的效果。
对于客户端和服务端之间需要频繁交互的复杂场景,比如网页游戏,都可以考虑使用websocket协议。
websocket和socket几乎没有任何关系,只是叫法相似。
正因为各个浏览器都支持HTTP协议,所以websocket会先利用HTTP协议加上一些特殊的header头进行握手升级操作,升级成功后就跟HTTP没有任何关系了,之后就用websocket的数据格式进行收发数据。
展开
评论
下一页
个人成就
文章被阅读 715
掘力值 185
收藏集
0
关注标签
4
加入于