java后端工程师进修ing（研一版‖day48）
目录
今日总结
详细内容
java随征录
jmeter压力测试
在进行git提交时，出现Empty repository 情况解决办法。
业务框架
技术架构图
科研随探录
八股随笔录
代码随想录
今日总结
- java随征录——搭配开发环境，jmeter压力测试
- 科研随探录——
- 八股随笔录——Redis面试篇(2/7)
- 代码随想录——
详细内容
java随征录
jmeter压力测试
在进行git提交时，出现Empty repository 情况解决办法。
在项目的根目录右键 Git Bash Here
输入以下指令，再次进入到push时，就会出现仓库了。
git commit -m "install commit!"
本项目基于B2B2C的业务模式，第一个B指商品或服务的供应商，第二个B指从事电子商务的企业，C则表示消费者。
B2B的定义：企业和企业之间的电子商务运作
B2C的定义：企业和消费者之间的电子商务运作
业务框架
核心模块：内容管理、媒资管理、课程搜索、订单支付、选课管理、认证授权等
本项目采用前后端分离架构，后端采用SpringBoot、SpringCloud技术栈开发，数据库使用了Mysql，Reids、消息队列，分布式文件系统、Elasticsearch等中间件系统
技术架构图
科研随探录
八股随笔录
- 哈希表是如何扩容的
进行rehash的时候，需要用上2个哈希表。
当触发rehash的时候，大致分为以下过程
1. 给哈希表2分配空间，一般比哈希表1大两倍
2. 给哈希表1的数据迁移到哈希表2中
3. 迁移完成后，哈希表1的空间会被释放，并把【哈希表2】设置为【哈希表1】，然后在【哈希表2】新创建一个空白的哈希表，为下次rehash做准备。
注意：在第二步时，会出现一些问题。当哈希表1的数据量非常大的时候，在迁移中会涉及大量的数据拷贝，此时可能会对redis造成阻塞，无法服务其他请求。
为了避免这种情况，因拷贝数据的耗时，影响redis性能的情况，采用渐进式rehash，进行分多次迁移。渐进式rehash的过程如下
1. 给哈希表2分配空间
2. 在rehash进行期间，每次哈希表元素进行新增、删除、查找或者更新操作时，redis除了执行响应的操作之外，会顺序将哈希表1中索引位置上的key-value迁移到哈希表2上。
3. 随着处理客户端发起的哈希表操作请求数量越来越多，在某个时刻所有的数据全部迁移到哈希表2，完成rehash操作。
另外，在渐进式rehash期间，新增数据时只会保存到哈希表2中，哈希表1不再进行任何添加操作。
- Redis为什么快？
单线程的reids吞吐量可以达到10w/秒，有以下几点原因
1. redis的大部分操作都是在内存中完成的，采用了高效的数据结构(字符串、哈希等等)。因此redis瓶颈是机器的内存或带宽，而不是cpu
2. redis采用单线程模型可以避免了多线程之间的竞争，省去了多线程切换带来的时间和性能上的开销，不会导致死锁问题
3. redis采用了I/O多路复用机制来处理大量的客户端Socket请求，指一个线程处理多个IO流。简单来说就是，在redis只运行单线程的情况下，该机制允许内核同时存在多个监听Socket，内核会一直监听这些Socket的请求
- Redis哪些地方使用了多线程？
Redis 单线程指的是「接收客户端请求->解析请求 ->进行数据读写等操作->发送数据给客户端」这个过程是由一个线程（主线程）来完成的。但是Redis程序并不是单线程的。
在Redis启动时，会启动后台线程，来进行（关闭文件、AOF刷盘、释放内存）这些任务。因为这些任务比较耗时，Redis主线程就很容易发生阻塞。
Redis 6.0 对于网络 I/O 采用多线程来处理。但是对于命令的执行，Redis 仍然使用单线程来处理，所以大家不要误解Redis 有多线程同时执行命令。
代码随想录