列表样式
编号列表的标记符为<ol>
,表示顺序列表
1 | <ol> |
效果为
项目符号列表的标记符为<ul>
,表示无序列表
1 | <ul> |
效果为
<li>
则使用在<ol>
或<ul>
中,来封装列表中的每一项
除此之外,还可以通过list-style-type
属性来设置样式,其可选项为
List属于单值多value,链表用的是双向链表结构,list支持pop、push来操作头部和尾部,既可以用做栈也可以用做队列
在3.2版本之前使用的是ziplist和linkedlist,在3.2版本之后使用的是quicklist
由于linkedlist的附加空间相对太高,prev和next指针就要占去16个字节,而且每个节点的内存都是单独分配,加剧了内存的碎片化,使用quicklist来代替之前的ziplist+linkedlist
1 | typedef struct quicklist { |
看代码好像底层还是使用的ziplist,而且还有前驱和后继指针,就是一个ziplist+linkedlist混合体,把多个ziplist使用双向指针串联起来了。
默认单个ziplist长度为8字节,使用 list-max-ziplist-size
来进行配置
1 | # For a fixed maximum size, use -5 through -1, meaning: |
linux中有几种IO模型,如select、poll、epoll,这几个分别是什么呢?
在select模型下是利用轮询socket句柄的方式来实现监测socket中是否有IO数据到达,每次调用select,都需要把fd集合从用户态拷贝到内核态,然后在内核态还要遍历一遍传进来的所有fd,在fd很多时开销很大
select默认支持的文件描述符是1024
poll模型与select类似,不过其是基于链表存储的,没有最大连接数限制,但是跟select一样,需要把fd集合在用户态和内核态之间来回复制
epoll改进了轮询socket句柄的方式,采用notify机制来进行监测,为每个fd指定一个回调函数,当设备就绪,唤醒等待队列上的等待者,就会调用这个回调函数
排查系统很慢的时候,先观察IO等待时间,如果IO等待时间很低,可以查看CPU空闲时间百分比;如果IO等待时间很高,需要确定是什么原因导致的IO等待时间占比这么高;如果IO等待时间很低,而且CPU空闲时间很高,那就不是CPU资源的问题,需要从其他地方找原因。
先使用uptime
命令
1 | uptime |
根据1分钟、5分钟、15分钟的平均负载来确定问题所处时间。
如果处于高负载状态,使用top
命令来观察是哪些进程在消耗CPU
使用iostat
命令可以查看是哪个分区正在执行大量的IO操作
有时候我们去查找的时候已经不是第一现场了,看实时的数据肯定是不行了。可以使用sar
命令来查看历史数据
1 | # 查看当天的CPU统计信息 |
我们可以使用redis来实现一个简单的滑动窗口限流,滑动窗口的话我们可以使用zset的score来进行实现。value需要保证唯一性,暂且使用时间戳。
通过统计该窗口内的行为数量和限制的最大数量maxCount进行比较就可以得出当前的请求是否允许
1 | public class RedisRateLimiter { |
如果时间窗口内允许的数量较大,会消耗大量的内存。则不适合该方式