#1024程序员节|征文#
在1024程序员节这个特别的日子里,首先,我想对每一位程序员表示最诚挚的祝贺!祝愿大家在未来的日子里,能够继续热爱编程、追求卓越,携手共创更美好的科技未来!让我们共同庆祝属于程序员的节日!
这篇主要讲解的是Linux命令、消息队列(RabbitMq等等)、Redis(击穿、穿透、雪崩等问题)
Liux命令
cd 切换目录
pwd 查看当前路径
mkdir 创建目录
mv 修改目录名称
ps -ef|grep java 查看java进程
kill -9 进程号 杀掉进程
tail -400f 文件名称 查看最后400行
tail -50f ./zookeeper.out |grep '/usr/local/src/java/' 搜索zookeeper.out日志包含的/usr/local/src/java/
vi 编辑文本
cat 查看文件
find文件
chmod 777 ./start.sh 给star.sh赋所有权限
top 查看服务器资源,比如内存,cpu使用情况
消息队列
RabbitMQ的死信队列和延时队列?
消息被拒,requeue设置 为 false
消息过期,队列达到最大程度 这时候会存放到死信队列中去。
设置消息过期时间:采用队列中的x-message-ttl 参数去设置,单位是毫秒
关于ActiveMQ、RocketMQ、RabbitMQ、Kafka一些总结和区别
为什么使用消息队列?
异步(发送手机验证码),
解耦(借款系统和风控系统),
削峰(秒杀,购买商品,放入消息队列排队)
使用消息队列有什么缺点?
(1).多了一个MQ服务,可能会出现单点故障,导致系统不可用(集群)
(2).消息队列重复消费幂等问题(一个操作无论执行多少次,都会自己业务没有任何影响)
(3).消息队列丢失问题
(4).消息队列顺序问题
消息队列如何选型?
ActiveMQ集群模式很复杂,它的集群模式是分片的,每个机器上只存了部分数据,万一服务挂了,数据就丢了,最高并发10万以内,社区活跃度比较低,对开发的系统安全有影响
RabbitMQ集群模式,可以保证服务挂了,不丢消息,最高并发10万以内,社区活跃度比较高
RocketMQ集群模式,可以保证服务挂了,不丢消息,最高并发10万以上,社区活跃度比较高
Kafka(集群模式,打点统计,日志统计),高并发100万
如何保证消息队列是高可用的?
集群
如何保证消息不被重复消费?
根据业务场景做幂等(1.比如唯一的信息我们可以建唯一索引,2.监听里面做校验幂等操作,3.每个消息分配一个唯一的id,uuid,消费完redis存一下,然后后面每次都进来校验下)
如何保证消息的顺序性?
1.保证一个生产者对应着一个消费者
2.监听器里面把消息消费放到JVM队列(LInkedBlockQueue),然后再消费本地队列
如何保证消息不丢失?
MQ发送消息到消费的整个过程分为3个阶段,生产者-MQ-消费者,
1.保证MQ服务的高可用,做集群,持久化
2.消费者在消费MQ里面的内容的时候,如果MQ保存了,MQ会有重试机制,重试还失败后会进入死信队列,然后消息丢失,这个过程可以采用ACK确认机制,手动签收消息,如果消费失败,让消息还是在MQ里面
如果消息在生产者发送到MQ的过程中,因为通讯网络问题,也可能会丢失,这个时候需要做消息持久化,我们会把消息存入到数据库,如果消费成功,把消息删除掉,当然删除消息可能会失败,后面我们可以通过定时任务轮询做补偿,然后继续忘消息队列里面发消息,那么这样可能会出现一个新问题,消息的重复消费,需要考虑幂等问题,我们消息持久化的时候都会分配一个msgId唯一标识,后面消费完了存入redis,消费之前校验一下就可以了
Redis
为什么使用redis?
1.支持高可用,3.0集群
2.丰富的数据类型
3.完全内存操作,速度快,支持持久化
4.存储数据大,单个key和value可以存储到1G
Redis 的持久化方式?
redis持久化方式有RDB和AOF ,RDB是方式是每过几秒保存的是redis数据的快照,但是可能会丢数据,AOF 保存的是所有在redis执行的命令,它会追加到一个文件里面,丢数据可能性小,但会导致文件很大,假如redis宕机了,恢复的时候会很慢,我们一般使用RDB,因为我们对redis的定位就是缓存服务器,很重要的数据我们不会存redis,比如与钱有关系。
Redis内存淘汰策略?
noeviction:直接返回错误,不淘汰任何已经存在的redis键
allkeys-lru:所有的键使用lru算法进行淘汰
volatile-lru:有过期时间的使用lru算法进行淘汰
allkeys-random:随机删除redis键
volatile-random:随机删除有过期时间的redis键
volatile-ttl:删除快过期的redis键
volatile-lfu:根据lfu算法从有过期时间的键删除
allkeys-lfu:根据lfu算法从所有键删除
redis有哪几种数据类型
string ,hash,list,set,zset
redis分布式锁底层原理?
redis分布式锁其实就是往redis设置一个key和value同时设置一个有效时间,并且redis是单线程的,不会并发操作,(执行任务完成后),再把redis的key删除掉(解锁),但是在使用的过程中可能有2个问题,使用过程中我们必须保证设置key和value和设置时间保证它的原子性(LUA),另外还是锁超时问题,比如:上锁2秒钟,但是任务执行超过2秒,我们一般用redission框架,它底层是lua脚本实现,可以保证设置值和时间的原子性,另外还有
看门狗的机制,watch dog,我们上锁3秒,但是任务执行5秒,它会自动加时间
为什么使用分布式锁?
因为我们的系统是分布式的,synchronized和lock锁只能是JVM级别的,这个时候需要分布式锁,它实现的思路: redis分布式锁其实就是往redis设置一个key和value同时设置一个有效时间,并且redis是单线程的,不会并发操作,(执行任务完成后),再把redis的key删除掉(解锁),这个过程需要注意的点是,必须保证设置key和value和设置时间保证它的原子性,不然可能出现死锁,另外一方面就是锁任务自动超时问题,所有我们一般用的redisson框架,它完美的帮我们封装了分布式锁,底层是基于LUA脚本实现保证原子性,同时redission
还有watch dog,比如我们上锁3秒,但是任务执行5秒,它会自动加时间
1.分布式锁{
redis查商品,3
校验随机码,
检验秒杀时间段,
商品id和随机码是不是一样,
检验每人限购数量,
检验库存,3
锁定库存(减库存)
下单消息队列
}
redis集群模式?
1.主从复制(缺点,主挂掉后,需要人工切换干预,不能保证服务的高可用)
2.哨兵模式(一主多从,主挂掉后,会自动选举主再提供服务,缺点:1.极端情况下网络不是很好的情况,选举需要花时间,可能服务不可用。2. 资源浪费,Redis 数据节点中 slave 节点作为备份节点 )
3.集群模式( Redis Cluster 是 3.0 版后推出的 Redis 分布式集群解决方案 )
1. 数据按照 slot 存储分布在多个节点,节点间数据共享,可动态调整数据分布。
2. 可扩展性:可线性扩展到 1000 多个节点,节点可动态添加或删除。
3. 高可用性:部分节点不可用时,集群仍可用。通过增加 Slave 做 standby 数据副本,能够实现故障自动 failover
redis哨兵(Sentinel)模式?
redis节点之间通过心跳检测,从服务器(slave)每过一段时间向主服务器(master)发送一个ping命令,主服务器的响应,如果主服务器挂了,所有从服务器通信,有一种算法选举为主,再提供服务
redis cluster原理?
所有的redis结点都是彼此互联的
客户端连接集群的时候不需要关心分片的计算逻辑,客户端直接将key交给redis中的结点,最终由内部判断key值的正确存储位置
redis集群是吧所有的主节点都交给对应的卡槽去处理【0-16383】,由主节点去维护一批数据。数据主要是被哪个结点维护是判断对应key的取模运算,如果要迁移某个key值,必须将对应的slot(槽)一并迁移
redis脑裂问题?
redis集群由于网络的原因可能会出现脑裂的问题,脑裂就是因为主服务器、从服务器和哨兵不在同一个网络中,导致哨兵没有及时的检测到主服务的心跳,在这个时候会在从服务器中去选举一个新的主服务器,这样就有两个主服务器了就像大脑分裂一样,但是这样会导致客户依旧 在旧的主服务器中去写东西,而新的主服务器中没有东西。当网络恢复后,哨兵会把旧的主服务器变成从服务器,这个 时候在去同步数据,可能会造成一个数据的丢失
解决方法:
redis中需要加入两个配置
(旧版本)
min-slaves-to-write 3 最少有3个从服务器
min-slaves-max-lag 10 数据复制和同步的延迟不超过10秒
(新版本)
min-replicas-to-write 3
min-replicas-max-lag 10
如果加了这两个配置的话,原来的主服务器当客户端再次进行写操作的时候会拒绝接受,此时就发送到新的主服务器中去了
什么是缓存和数据库双写不一致?怎么解决?
数据的信息和缓存由于并发或者其中一个失败导致不一致
解决方案:我们一般是先修改数据库,再删除缓存,因为我们对redis的定位是缓存,redis可能会丢数据,首先保证我们的数据库必须更新,如果redis删除失败,我们采用补偿策略,比如错误了或失败了,把信息放MQ,做消费补偿
缓存雪崩是指:由于缓存中的数据一下子全部都在同一时间过期了,所以发送过来的全部请求都去请求数据库,导致数据库难以承受而宕机。
解决方法:
- 可以保证 redis高可用,建集群;
- 设置不同的过期时间,防止全部在同一时间过期
缓存穿透是指:缓存和数据库中都没有数据,如果有人恶意访问的会先去缓存查询,此时缓存中无数据,后在去数据库中去查询,数据库中也没有,这个时候就会导致数据库宕机
解决方法:
可以在缓存中设置一个null值,让恶意的请求不会直接击垮数据库,每次访问的时候都去访问此缓存。
可以设计一个过滤器,常用的就是布隆过滤器(可以缓解,为什么是缓解,因为使用过滤器还会造成误判的情况)
缓存击穿是指:一条数据在查询的时候突然过期了,那么就所有的请求都打在数据库上
解决方法:
加锁,只让一个人去访问数据库并且将访问的数据存入缓存中,供其他的请求来访问