victory的博客

长安一片月,万户捣衣声

0%

上下文切换和死锁

上下文切换

CPU通过时间片分配算法来循环执行任务,当前任务执行一个时间片后会切换到下一个任务。但是,再切换前会保存上一个任务的
状态,以便切换回这个任务时,可以再加载这个任务的状态。所以任务从保存到再加载的过程就是一次上下文切换。频繁的上下文
切换会影响多线程的执行速度。

如何减少上下文切换

(1)无锁并发编程。多线程竞争锁时,会引起上下文切换,所以多线程处理数据时,可以用一些办法来避免使用锁(如采用分段锁,不同的线程处理不同段的数据)
(2)CAS算法。
(3)使用最小线程。避免创建不需要的线程(任务很少,创建了很多线程,造成大量线程阻塞等待)

死锁

死锁产生的条件

(1)互斥。一个资源同一时刻只能被一个线程拥有。
(2)请求和保持。线程在请求新的资源时,不释放已经拥有的资源。
(3)不剥夺条件。进程所获得的资源在未使用完之前,不被其他的线程强行剥夺。
(4)循环等待。竞争资源的各个线程形成一个线程等待环路。

避免死锁

破坏产生死锁的条件:
(2)在进程开始执行时就申请他所需的全部资源
(3)一个进程不能获得所需要的全部资源时便处于等待状态,等待期间他占有的资源将被隐式的释放重新加入到系统的资源列表中
,可以被其他的进程使用,而等待的进程只有重新获得自己原有的资源以及新申请的资源才可以重新启动、执行。
(4)资源有序分配(银行家算法)

死锁Demo

package concurrency;

public class DeadLockDemo {
    private static String A = "A";
    private static String B = "B";
    
    public static void main(String[] args) {
        new DeadLockDemo().deadLock();
    }
    
    private void deadLock(){
        Thread t1 = new Thread(new Runnable(){
            @Override
            public void run(){
                synchronized(A){
                    try {
                        Thread.currentThread().sleep(2000);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    synchronized(B){
                        System.out.println("1");
                    }
                }
            }
        });
        
        Thread t2 = new Thread(new Runnable(){
            @Override
            public void run() {
                synchronized(B){
                    synchronized(A){
                        System.out.println("2");
                    }
                }
            }
        });
        
        t1.start();
        t2.start();
    }
}

缓存和数据库的一致性问题

1、想要提高应用的性能,可以引入「缓存」来解决
2、引入缓存后,需要考虑缓存和数据库一致性问题,可选的方案有:「更新数据库 + 更新缓存」、「更新数据库 + 删除缓存」
3、更新数据库 + 更新缓存方案,在「并发」场景下无法保证缓存和数据一致性,且存在「缓存资源浪费」和「机器性能浪费」的情况发生
4、在更新数据库 + 删除缓存的方案中,「先删除缓存,再更新数据库」在「并发」场景下依旧有数据不一致问题,解决方案是「延迟双删」,但这个延迟时间很难评估,所以推荐用「先更新数据库,再删除缓存」的方案
5、在「先更新数据库,再删除缓存」方案下,为了保证两步都成功执行,需配合「消息队列」或「订阅变更日志」的方案来做,本质是通过「重试」的方式保证数据一致性
6、在「先更新数据库,再删除缓存」方案下,「读写分离 + 主从库延迟」也会导致缓存和数据库不一致,缓解此问题的方案是「延迟双删」,凭借经验发送「延迟消息」到队列中,延迟删除缓存,同时也要控制主从库延迟,尽可能降低不一致发生的概率
参考资料

Redis集群搭建

1.下载Redis并将redis放到linux目录/opt下
2.在opt下创建myRedis文件夹,并备份redis.conf到此处
3.安装ruby环境
(1)yum install ruby
(2)yum install rubygems
4.创建6个实例(此处使用相同主机的不同端口来模拟多个节点)
通过include引入备份文件redis.conf(redis.conf中需要修改配置:protected-mode no daemonize yes appendonly no)的内容并修改每个节点不同的信息
(1)redis6379.conf

include /opt/myRedis/redis.conf
pidfile "/var/run/redis6379.pid"
port 6379
dbfilename "dump6379.rdb"
cluster-enabled yes
cluster-config-file nodes-6379.conf
cluster-node-timeout 15000

(2)redis6380.conf

include /opt/myRedis/redis.conf
pidfile "/var/run/redis6380.pid"
port 6380
dbfilename "dump6380.rdb"
cluster-enabled yes
cluster-config-file nodes-6380.conf
cluster-node-timeout 15000

(3)redis6381.conf

include /opt/myRedis/redis.conf
pidfile "/var/run/redis6381.pid"
port 6381
dbfilename "dump6381.rdb"
cluster-enabled yes
cluster-config-file nodes-6381.conf
cluster-node-timeout 15000

(4)redis6389.conf

include /opt/myRedis/redis.conf
pidfile "/var/run/redis6389.pid"
port 6389
dbfilename "dump6389.rdb"
cluster-enabled yes
cluster-config-file nodes-6389.conf
cluster-node-timeout 15000

(5)redis6390.conf

include /opt/myRedis/redis.conf
pidfile "/var/run/redis6390.pid"
port 6390
dbfilename "dump6390.rdb"
cluster-enabled yes
cluster-config-file nodes-6390.conf
cluster-node-timeout 15000

(6)redis6391.conf

include /opt/myRedis/redis.conf
pidfile "/var/run/redis6391.pid"
port 6391
dbfilename "dump6391.rdb"
cluster-enabled yes
cluster-config-file nodes-6391.conf
cluster-node-timeout 15000

5.启动所有redis实例,nodes-xxxx.conf文件都生成正常。

6.将六个实例组合到一个集群当中

redis-cli --cluster create 192.168.1.108:6379 192.168.1.108:6380 192.168.1.108:6381 192.168.1.108:6389 192.168.1.108:6390 192.168.1.108:6391 --cluster-replicas 1

7.启动客户端并查看集群

Redis关闭服务报错

在linux中执行redis-cli shutdown命令来关闭redis服务时报错:

(error) ERR Errors trying to SHUTDOWN. Check logs.

解决办法

1)执行vim命令打开redis.conf文件

vim redis.conf

2)在配置文件中找到logfile “”,并修改为 logfile “/opt/myRedis/redis_log.log”
3)修改日志文件redis_log.log的文件权限

sudo chmod 777 /opt/myRedis/redis_log.log

4)强制关闭redis服务

kill -9 当前redis服务的进程号

5)重启redis服务(案例将redis的配置文件做了备份,放在/opt/myRedis/目录下)

redis-server redis.conf

Redis集群

  1. 问题
    1)服务器内存容量不够,redis如何进行扩容?
    2)大量并发写操作, redis如何分摊?
  2. 集群
    Redis 集群实现了对Redis的水平扩容,即启动N个redis节点,将整个数据库分布存储在这N个节点中,每个节点存储总数据的1/N
    注:Redis 集群通过分区(partition)来提供一定程度的可用性(availability): 即使集群中有一部分节点失效或者无法进行通讯, 集群也可以继续处理命令请求。
  3. slots
    一个 Redis 集群包含 16384 个插槽(hash slot), 数据库中的每个键都属于这 16384 个插槽的其中一个, 集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽, 其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。
    集群中的每个节点负责处理一部分插槽。举个例子, 如果一个集群可以有主节点,其中:节点A负责处理0号至5500号插槽,节点B负责处理5501号至11000号插槽,节点C负责处理11001号至16383号插槽。
  4. 集群的优点
    1)实现扩容
    2)分摊压力
    3)无中心配置相对简单
  5. 集群的缺点
    1)多键操作是不被支持的(这些键有可能存在不同的服务器上,可以通过{}来定义组的概念,从而使key中{}内相同内容的键值对放到一个slot中去。)
    2)多键的Redis事务是不被支持的。lua脚本不被支持。
    3)由于集群方案出现较晚,很多公司已经采用了其他的集群方案,而代理或者客户端分片的方案想要迁移至redis cluster,需要整体迁移而不是逐步过渡,复杂度较大。

Redis主从复制

  1. 主从复制
    主机数据更新后根据配置和策略,自动同步到备机的master/slaver机制,master以写为主,slave以读为主
  2. 复制原理
    (1)每次从机联通后,都会给主机发送sync指令
    (2)主机立刻进行存盘操作并发送RDB文给从机
    (3)从机收到RDB文件后,进行全盘加载
    (4)之后每次主机的写操作,都会立刻发送给从机,从机执行相同的命令
  3. 哨兵模式
    能够后台监控主机是否故障,如果故障了根据投票数自动将从机转换为主机
  4. 故障恢复
    (1)如果发生故障,从下线的主服务的所有从服务里挑选一个从服务,将其转成主服务
    选择条件:
    1)选择优先级靠前的(优先级可以在redis.conf中设置slave-priority)
    2)选择偏移量最大的(偏移量最大指获得原主服务数据最多的服务)
    3)选择runid最小的从服务(每个Redis实例启动后都会随机生成一个40为的runid)
  5. 优点
    (1)读写分离
    (2)容灾快速恢复

Redis持久化方式

  1. 两个不同形式得持久化方式
    RDB(Redis DataBase)
    AOF(Append Of File)
  2. RDB
  3. 1 RDB
    在指定的时间间隔内将内存中的数据集快照(Snapshot)写入磁盘,恢复时将快照文件直接读到内存中。
  4. 2 备份
    Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能;
  5. 3 适用
    大规模数据的恢复且对于数据恢复的完整性不是非常敏感
  6. 4 优点
    1)节省磁盘空间
    2)恢复速度快
  7. 5 缺点
    1)虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
    2)在备份周期在一定间隔时间做一次备份,所以如果Redis意外down掉的话,就会丢失最后一次快照后的所有修改。
  8. AOF
  9. 1 AOF
    以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以改写文件,Redis启动之初会读取该文件重新构建数据,换言之,Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
  10. 2 AOF同步频率设置:
    1)始终同步
    2)每秒同步
    3)不主动进行同步
  11. 3 Rewrite:
    AOF采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制,当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof。

如何实现重写?
AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename),遍历新进程的内存中数据,每条记录有一条的Set语句。重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似。
何时重写
系统载入时或者上次重写完毕时,Redis会记录此时AOF大小,设为base_size,如果Redis的AOF当前大小>= base_size +base_size*100% (默认)或当前大小>=64mb(默认)的情况下,Redis会对AOF进行重写。
3.4 AOF的优点:
1)备份机制更稳健,丢失数据概率更低。
2)可读的日志文本,通过操作AOF文件,可以处理误操作。
3.5 AOF的缺点:
1)比起RDB占用更多的磁盘空间。
2)恢复备份速度要慢。
3)每次读写都同步的话,有一定的性能压力。
4)存在个别Bug,造成不能恢复。
注意:
1)AOF和RDB同时开启,系统默认取AOF的数据
2)推荐AOF和RDB都使用
3)如果对数据不敏感,可以选单独用RDB
4)不建议单独用 AOF,因为可能会出现Bug
5)如果只是做纯内存缓存,可以都不用

秒杀

秒杀需要解决的问题

解决商品库存计数器和秒杀成功的用户记录的事务操作

秒杀遇到的三个问题

1.连接超时问题 —> 使用Redis连接池
2.超卖(卖出的商品数量超过商品库存数量) —> 使用事务
3.库存遗留问题(并发的请求中只有一个请求能够秒杀成功造成库存遗留) —> 使用lua脚本

阅读全文 »

事务

Redis中事务的定义

Redis事务是一个单独的隔离操作:事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断
Redis事务的主要作用就是串联多个命令防止别的命令插队

事务相关的命令(multi、exec、discard)

1.从输入Multi命令开始,输入的命令都会依次进入命令队列中,但不会执行,至到输入Exec后,Redis会将之前的命令队列中的命令依次执行。
2.组队的过程中可以通过discard来放弃组队。

阅读全文 »