科技新闻

“小明，多系统的session共享，怎么处理？”“Redis缓存啊！” “小明，我想实现一个简单的消息队列？”“Redis缓存啊！” “小明，分布式锁这玩意有什么方案？”“Redis缓存啊！” “小明，公司系统响应如蜗牛，咋整？”“Redis缓存啊！” 本着研究的精神，我们来分析下小明的第四个问题。 准备： Idea2019.03/Gradle6.0.1/Maven3.6.3/JDK11.0.4/Lombok0.28/SpringBoot2.2.4RELEASE/mybatisPlus3.3.0/Soul2.1.2/ Dubbo2.7.5/Druid1.2.21/Zookeeper3.5.5/Mysql8.0.11/Vue2.5/Redis3.2 难度：新手-- 战士 --老兵--大师 目标： Spring优雅整合Redis做数据库缓存 步骤： 为了遇见各种问题，同时保持时效性，我尽量使用最新的软件版本。源码地址： https://github.com/xiexiaobiao/vehicle-shop-admin 1 先说结论 Redis缓存不是金弹，若系统DB毫无压力，系统性能瓶颈不在DB上，不建议强加缓存层！ 增加业务复杂度：同一缓存必须被全部相关方法所覆盖，如订单缓存，只要涉及到订单数据更新的方法都要进行缓存逻辑处理。 同时，KV存储时，因各方法返回的类型不同

Z ooK eeper 保证数据一致性用的是 ZAB协议 。 通过这个协议来进行 Z ooK eeper 集群间的数据同步，保证数据的一致性。 两阶段提交+过半写机制： Z ooK eeper 写数据的机制是客户端把写请求发送到leader节点上（如果发送的是follower节点，follower节点会把写请求转发到leader节点），leader节点会把数据通过proposal请求发送到所有节点（包括自己），所有到节点接受到数据以后都会写到自己到本地磁盘上面，写好了以后会发送一个ack请求给leader，leader只要接受到过半的节点发送ack响应回来，就会发送commit消息给各个节点，各个节点就会把消息放入到内存中（放内存是为了保证高性能），该消息就会用户可见了。 那么这个时候，如果 Z ooK eeper 要想保证数据一致性，就需要考虑如下两个情况，情况一： leader执行commit了，还没来得及给follower发送commit的时候，leader宕机了，这个时候如何保证消息一致性？ 情况二： 客户端把消息写到leader了，但是leader还没发送proposal消息给其他节点，这个时候leader宕机了，leader宕机后恢复的时候此消息又该如何处理？ ZAB的崩溃恢复机制 针对情况一，当leader宕机以后， Z ooK eeper 会选举出来新的leader

原创声明 本文作者：黄小斜 转载请务必在文章开头注明出处和作者。 什么是消息队列 “RabbitMQ？”“Kafka？”“RocketMQ？”...在日常学习与开发过程中，我们常常听到消息队列这个关键词，可能你是熟练使用消息队列的老手，又或者你是不懂消息队列的新手，不论你了不了解消息队列，本文都将带你搞懂消息队列的一些基本理论。如果你是老手，你可能从本文学到你之前不曾注意的一些关于消息队列的重要概念，如果你是新手，相信本文将是你打开消息队列大门的一板砖。 根据百度百科的说法，“消息队列”是在消息的传输过程中保存消息的容器。消息队列管理器在将消息从它的源中继到它的目标时充当中间人。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。` 为什么要使用消息队列 我觉得使用消息队列主要有两点好处： 1.通过异步处理提高系统性能（削峰、减少响应所需时间）; 2.降低系统耦合性。如果在面试的时候你被面试官问到这个问题的话，一般情况是你在你的简历上涉及到消息队列这方面的内容，这个时候推荐你结合你自己的项目来回答。 《大型网站技术架构》第四章和第七章均有提到消息队列对应用性能及扩展性的提升。 在我平时的日常工作中，用到消息队列的场景可不少，比如，我有一个定时任务需要在A应用每天7点开始调度，那么定时任务系统如何告诉这个A应用呢

一、认识消息队列 1.1 消息对列概念 　　从本质上说消息对列就是一个队列结构的中间件，也就是说消息放入这个中间件之后就可以直接返回，并不需要系统立即处理，而另外会有一个程序读取这些数据，并按顺序进行逐次处理。 　　也就是说当你遇到一个并发特别大并且耗时特别长同时还不需要立即返回处理结果，使用消息队列可以解决这类问题。 1.2 核心结构 由一个业务系统进行入队，把消息逐次插入到消息队列中，插入成功之后直接返回成功的结果，后续会有一个消息处理系统，这个系统会把消息系统中的记录逐次进行取出并进行处理，完成一个出队的流程。 1.3 应用场景 　　数据冗余：比如订单系统，后续需要严格的进行数据转换和记录，消息队列可以把这些数据持久化的存储在队列中，然后有订单，后续处理程序进行获取，后续处理完之后在把这条记录进行删除来保证每一条记录都能够处理完成。 　　系统解耦：使用消息系统之后，入队系统和出队系统是分开的，也就说只要一天崩溃了，不会影响另外一台系统正常运转。 　　流量削峰：例如秒杀和抢购，我们可以配合缓存来使用消息队列，能够有效的顶住瞬间访问量，防止服务器承受不住导致崩溃。 　　异步通信：消息本身使用入队之后可以直接返回。 　　扩展性：例如订单队列，不仅可以处理订单，还可以给其他业务使用。 　　排序保证：有些场景需要按照产品的顺序进行处理比如单进单出从而保证数据按照一定的顺序处理

promise的使用方法 promise简介 是异步编程的一种解决方案。从语法上说，Promise 是一个对象，从它可以获取异步操作的消息。解决回调函数嵌套过多的情况 const promise =new Promise(function(resolve,reject){ setTimeout(function(){ resolve('执行成功') },3000) }) promise.then(res=>{ console.log(res) }).catch(err=>{ console.log(err) }) console.log(111) 等待三秒后输出 ‘执行成功’,也就是说当异步操作完成，即执行resolve或者reject之后，才会执行then中的操作 其他用法 promise.all([]) 所有请求都完成时再执行后续操作 var p1 = Promise.resolve(3); var p2 = 1337; var p3 = new Promise((resolve, reject) => { setTimeout(resolve, 100, 'foo'); }); Promise.all([p1, p2, p3]).then(values => { console.log(values); // [3, 1337, "foo"] }); promise.race

2020/04/03日消息： https://spring.io/blog/2020/04/03/spring-boot-2-3-0-m4-available-now Spring团队正式发布了 Spring Boot 2.3 的第 4 个里程碑版本，现在可以从 Spring 的里程碑仓库获取了： https://repo.spring.io/milestone/ 这个版本主要关闭了 99 个 99 issues 以及 pull requests，详细可以看这个版本说明： https://github.com/spring-projects/spring-boot/releases/tag/v2.3.0.M4 主要可以包含以下 3 点： 1、支持 Kubernetes 容器探针(liveness and readiness probe) 在 Kubernates 中，容器探针代表了应用程序状态的各个方面，这个特性在这个版本中得到支持，计划在下个版本中还会增加对 Kubernates 主题的支持。 2、改进了对构建 OCI 映像的支持 当用 Maven/ Gradle 构建 OCI 映像时，现在开始支持 DOCKER_* 开始的环境变量定位 Docker Daemon 进程。 Docker Daemon 是 Docker 中的守护进程，Docker 客户端需要通过与 Docker

kafka运维常用查询操作总结以下几点： kafka生产和消费消息测试 发送：bin/kafka-console-producer.sh --broker-list 10.46.200.165:9092 --topic contentApprove 接收：bin/kafka-console-consumer.sh --bootstrap-server 10.46.200.165:9092 --topic contentApprove --from-beginning 创建topic命令参考 .bin/kafka-topics.sh --create --zookeeper localhost:2181 --partitions 6 --replication-factor 2 --topic test ### --partition：创建分区数，一般可以是服务器数量的双倍 ### --replication-factor：副本数默认为1，表示没有副本。保证冗余必须最少2 kafka修改副本数 bin/kafka-reassign-partitions.sh --zookeeper 10.124.77.41:2181 --reassignment-json-file test.json –execute 将分区数3修改为9 bin/kafka-topics.sh -

一、插件相关常用命令 1、查看所有已经安装的插件 cordova plugin ls 2、安装插件（以camera插件为例） cordova plugin add cordova-plugin-camera 3、删除插件（以camera插件为例） cordova plugin rm cordova-plugin-camera 4、更新插件 cordova plugin update 二、常用的Cordova插件 1、Console（调试控制台） 让程序可以在控制台中打印输出日志。 cordova plugin add cordova-plugin-console 2、Connection（网络连接） 用来判断网络连接类型（2G、3G、4G、Wifi、无连接等） cordova plugin add cordova-plugin-network-information 3、Device（设备） 获取一些设备信息。 4、Hardware Nofifications（硬件消息提醒） 让设备蜂鸣或振动。 cordova plugin add cordova-plugin-vibration 5、Visual Notification（可视化消息提醒） 不同于js的alert()、confirm()和prompt()方法是同步的。Cordova的alert()、confirm(

一、Docker概述 LXC所实现的隔离性主要是来自kernel的namespace, 其中pid, net, ipc, mnt, uts 等namespace将container的进程, 网络, 消息, 文件系统和hostname 隔离开。 cgroups 实现了对资源的配额和度量。 cgroups 的使用非常简单，提供类似文件的接口，在 /cgroup目录下新建一个文件夹即可新建一个group，在此文件夹中新建task文件，并将pid写入该文件，即可实现对该进程的资源控制。 二、网络 （1）网络模型 bridge：网桥网络 当Docker进程启动时，会在主机上创建一个名为docker0的虚拟网桥，此主机上启动的Docker容器会连接到这个虚拟网桥上。虚拟网桥的工作方式和物理交换机类似，这样主机上的所有容器就通过交换机连在了一个二层网络中。 host：主机网络 如果启动容器的时候使用host模式，那么这个容器将不会获得一个独立的Network Namespace，而是和宿主机共用一个Network Namespace。容器将不会虚拟出自己的网卡，配置自己的IP等，而是使用宿主机的IP和端口。但是，容器的其他方面，如文件系统、进程列表等还是和宿主机隔离的。 none：禁用容器网络 container：容器网络 这个模式指定新创建的容器和已经存在的一个容器共享一个 Network

redis相关 1.redis 发布 PUBLISH 发送消息 publish channel 消息 订阅 SUBSCRIBE 订阅消 等待发送者，向管道发送消息 subscribe channel channel2 channel3 频道 channel 自定义频道的名字 支持正则的频道订阅 psubscribe 支持正则的频道 publish channel 消息 redis数据持久化 redis数据放在内存中 重启服务器丢失数据 重启redis服务丢失数据 断电丢失数据 为了防止redis数据丢失，进行持久化，将数据，写入到一个文件中 redis持久化之RDB 1.基于内存的数据快照 2.定期执行数据快照 3.手动触发数据快照 如何配置rdb数据持久化 1.在配置文件中，添加rdb持久化参数 redis-6379.conf 写入如下配置 [root@qishione redis-4.0.10]# cat redis-6379.conf port 6379 daemonize yes pidfile /data/6379/redis.pid loglevel notice logfile "/data/6379/redis.log" dir /data/6379 protected-mode yes dbfilename dbmp.rdb save 900 1 save 300