万瑞萍
获得徽章 2
- #青训营笔记创作活动#
2月9日 打卡day1
今日学习了限流的相关方法，链接附在下方。
限流是限制到达系统的并发请求数量，保证系统能够正常响应部分用户请求，而对于超过限制的流量，则通过拒绝服务的方式保证整体系统的可用性。限流是高并发场景下的常用方法之一，常用的限流方法有计数器、滑动窗口、漏桶、令牌桶等方法。这些方法在实际使用上各有优劣，需要结合使用场景具体问题具体分析，选择合适的限流方法展开评论点赞 - #青训营笔记创作活动#
2月7日 打卡day18
今日学习了Flowable
现在市面上主流的流程引擎有三个：Activiti、Flowable、Camunda。这三个各有特点：Activiti 目前是侧重云，他目前的设计会向 Spring Cloud、Docker 这些去靠拢。Flowable 核心思想还是在做一个功能丰富的流程引擎工具，除了最最基础的工作流，他还提供了很多其他的扩展点，我们可以基于 Flowable 实现出许多我们想要的功能（当然这也是小伙伴们觉得 Flowable 使用复杂的原因之一）。Camunda 相对于前两个而言比较轻量级，Camunda 有一个比较有特色的功能就是他提供了一个小巧的编辑器，基于 bpmn.io 来实现的（松哥之前已经发文讲过了）。如果你的项目需求是做一个轻巧的、灵活的、定制性强的编辑器，工作流是嵌入式的，那么可以选择 Camunda。展开评论点赞 - #青训营笔记创作活动#
2月5日 打卡day17
今日学习了分库分表
分库分表是分别的两个概念 ，通过一定的规则，将原本数据量大的数据库拆分成多个单独的数据库，将原本数据量大的表拆分成若干个数据表，使得单一的库、表性能达到最优的效果（响应速度快），以此提升整体数据库性能。因为数据库容量有限，连接数有限，单表容量有限，因而实际场景中为了提高性能，需要分库分表。
分库分表的核心就是对数据的分片（Sharding）并相对均匀的路由在不同的库、表中，以及分片后对数据的快速定位与检索结果的整合。
分库分表后需要使用一定的路由规则来找到数据，常见的有取模算法 、范围限定算法、范围+取模算法 、预定义算法。
分库分表存在分页、排序、跨节点联合查询，事务一致性，全局唯一的主键，多数据库高效治理，历史数据迁移等问题。
分库分表架构主要有两种模式：client客户端模式和proxy代理模式展开评论点赞 - #青训营笔记创作活动#
2月4日 打卡day16
今日学习了高并发场景的一些知识
秒杀其实是一直瞬时高并发的场景，为应对这种场景，一般通过以下几个方面入手设计系统：页面静态化、CDN加速、缓存、mq异步处理、限流、分布式锁。
页面静态化即活动页面绝大多数内容是固定的，只有到了秒杀时间点，并且用户主动点了秒杀按钮才允许访问服务端。且根据用户位置使用CDN(Content Delivery Network，即内容分发网络)加速。
秒杀按钮使用js文件控制，为了性能考虑，一般会将css、js和图片等静态资源文件提前缓存到CDN上，让用户能够就近访问秒杀页面。分布式锁可以解决缓存击穿的问题，下单功能做成mq异步处理。限流一般有基于nginx限流和基于redis限流两种方法。展开评论点赞 - #青训营笔记创作活动#
2月3日 打卡day15
今日学习了redis
redis是一款优秀的缓存中间件，在客户端与数据层之间作为缓存层来分担请求压力。redis的优点是完全基于内存操作，性能极高，读写速度快；支持高并发；支持主从模式，支持读写分离与分布式；具有丰富的数据类型与丰富的特性（发布订阅模式）；支持持久化操作，不会丢失数据。缺点是数据库容量受到物理内存的限制，不能实现海量数据的高性能读写；相比关系型数据库，不支持复杂逻辑查询，且存储结构相对简单；虽然提供持久化能力，但实际更多是一个 disk-backed 功能，与传统意义上的持久化有所区别。
redis高性能的原因是完全基于内存；数据结构简单，操作方便，并且不同数据结构能够应对于不同场景；采用单线程（网络请求模块使用单线程，其他模块仍用了多线程），避免了不必要的上下文切换和竞争条件，也不存在多进程或多线程切换导致CPU消耗，不需要考虑各种锁的问题；使用多路I/O复用模型，为非阻塞I/O；本身设定了 VM 机制，没有使用 OS 的Swap，可以实现冷热数据分离，避免因为内存不足而造成访问速度下降的问题。展开评论点赞 - #青训营笔记创作活动#
2月2日 打卡day14
今天学习了加密相关的知识
非对称加密指加密和解密用到的不是同一个秘钥，而是两个不一样的秘钥，分别是公钥和私钥。公钥负责加密，私钥负责解密。公钥人人可得，私钥永远不泄露。
在HTTP层之上再加一层TLS层，目的就是为了做个加密，这就成了我们常说的HTTPS。
TCP握手后，HTTPS还需要经历两个阶段的加密。第一阶段是TLS四次握手，这一阶段主要是利用非对称加密的特性各种交换信息，最后得到一个"会话秘钥"。第二阶段是则是在第一阶段的"会话秘钥"基础上，进行对称加密通信。
TLS四次握手的过程中涉及到两对私钥和公钥。分别是服务器本身的私钥和公钥，以及CA的私钥和公钥。展开评论点赞 - #青训营笔记创作活动#
1月30日 打卡day13
今日学习了SQL语句相关的内容。
SQL语句室友客户端产生的，一般可以手动产生，或者由ORM框架产生。产生后去获取数据库连接，当网络连接建立成功后，也就等价于在MySQL中创建了一个客户端会话，经过验证用户名密码、查找空闲线程、获取当前登录用户的权限信息并授权等工作后，执行SQL语句的通道被打通。
接下来是执行过程：
1.先将SQL发送给SQL接口，SQL接口会对SQL语句进行哈希处理。
2.SQL接口在缓存中根据哈希值检索数据，如果缓存中有则直接返回数据。
3.缓存中未命中时会将SQL交给解析器，解析器会判断SQL语句是否正确，错误则抛出1064错误码及相关的语法错误信息，正确则将SQL语句交给优化器处理，进入第4步。
4.优化器根据SQL制定出不同的执行方案，并择选出最优的执行计划。
5.工作线程根据执行计划，调用存储引擎所提供的API获取数据。
6.存储引擎根据API调用方的操作，去磁盘中检索数据（索引、表数据....）。
7.发生磁盘IO后，对于磁盘中符合要求的数据逐条返回给SQL接口。
8.SQL接口会对所有的结果集进行处理（剔除列、合并数据....）并返回。
SQL语句的执行过程，实际上也就是MySQL的架构中一层层对其进行处理。展开评论点赞 - #青训营笔记创作活动#
1月23日 打卡day12
今日学习了MySQL的架构。
MySQL的整体架构从上往下看，依次会分为网络连接层、系统服务层、存储引擎层、以及文件系统层，往往编写SQL后，都会遵守着MySQL的这个架构往下走。
连接层：主要是指数据库连接池，会负责处理所有客户端接入的工作。
服务层：主要包含SQL接口、解析器、优化器以及缓存缓冲区四块区域。
存储引擎层：这里是指MySQL支持的各大存储引擎，如InnoDB、MyISAM等。
文件系统层：涵盖了所有的日志，以及数据、索引文件，位于系统硬盘上。
除此之外，MySQL的客户端可以使用各种语言编写的，客户端负责编写SQL，而服务端则负责SQL的执行与数据的存储。展开评论点赞 - #青训营笔记创作活动#
1月22日 打卡day11
今日学习了502问题排查的方法。
HTTP中5XX的状态码是服务器有问题的意思，但是服务器出问题了可能并不会返回状态码，所以说，一般情况下5xx的状态码其实并不是服务器返回给客户端的。它们是由网关返回的，常见的网关，比如nginx。
nginx网关充当中间层，帮助客户端与多个服务器通信，客户端直连nginx，再由nginx直连服务端。于是，当服务器发生异常时，nginx发送给服务器的那条TCP连接就不能正常响应，nginx在得到这一信息后，就会返回5xx错误码给客户端，也就是说5xx的报错，其实是由nginx识别出来，并返回给客户端的，服务端本身，并不会有5xx的日志信息。如果发现502，优先通过监控排查服务端应用是否发生过崩溃重启，如果是的话，再看下是否留下过崩溃堆栈日志，如果没有日志，看下是否可能是oom或者是其他原因导致进程主动退出。如果进程也没崩溃过，去排查下nginx的日志，看下是否将请求打到了某个不知名IP端口上。展开评论点赞 - #青训营笔记创作活动#
1月21日 打卡day10
今日学习了优秀后端都应该具备的开发好习惯：
1.注释尽可能全面,写有意义的方法注释
2.项目拆分合理的目录结构
3. 不在循环里远程调用、或者数据库操作，优先考虑批量进行。
4. 封装方法形参
5. 封装通用模板
6. 封装复杂的逻辑判断条件
7. 保持优化性能的嗅觉
8. 可变参数的配置化处理
9. 会总结并使用工具类
10. 控制方法函数复杂度
11. 在finally块中对资源进行释放
12.把日志打印好
13. 考虑异常，处理好异常
14. 考虑系统、接口的兼容性
15. 代码采取措施避免运行时错误展开评论点赞