我们一直说Redis的性能很快，那为什么快？Redis为了达到性能最大化，做了哪些方面的优化呢？在深度解析Redis的数据结构这篇文章中，其实从数据结构上分析了Redis性能高的一方面原因。 在目前的k-v数据库的技术选型中，Redis几乎是首选的用来实现高性能缓存的方案，它的性能有多快呢？ 根据官方的基准测试数据，一台普通硬件配置的Linux机器上运行单个Redis实例，处理简单命令（O(n)或者O（logn）），QPS可以达到8W，如果使用pipeline批处理功能，QPS最高可以达到10W。 Redis 为什么那么快Redis的高性能主要依赖于几个方面。 C语言实现，C语言在一定程度上还是比Java语言性能要高一些，因为C语言不需要经过JVM进行翻译。 纯内存I/O，内存I/O比磁盘I/O性能更快 I/O多路复用，基于epoll的I/O多路复用技术，实现高吞吐网络I/O 单线程模型，单线程无法利用到多核CPU，但是在Redis中，性能瓶颈并不是在计算上，而是在I/O能力，所以单线程能够满足高并发的要求。 从另一个层面来说，单线程可以避免多线程的频繁上下文切换以及同步锁机制带来的 ...

线程池的监控很重要，对于前面章节讲的动态参数调整，其实还是得依赖于线程池监控的数据反馈之后才能做出调整的决策。还有就是线程池本身的运行过程对于我们来说像一个黑盒，我们没办法了解线程池中的运行状态时，出现问题没有办法及时判断和预警。 对于监控这类的场景，核心逻辑就是要拿到关键指标，然后进行上报，只要能实时拿到这些关键指标，就可以轻松实现监控以及预警功能。 ThreadPoolExecutor中提供了以下方法来获取线程池中的指标。 getCorePoolSize()：获取核心线程数。 getMaximumPoolSize：获取最大线程数。 getQueue()：获取线程池中的阻塞队列，并通过阻塞队列中的方法获取队列长度、元素个数等。 getPoolSize()：获取线程池中的工作线程数（包括核心线程和非核心线程）。 getActiveCount()：获取活跃线程数，也就是正在执行任务的线程。 getLargestPoolSize()：获取线程池曾经到过的最大工作线程数。 getTaskCount()：获取历史已完成以及正在执行的总的任务数量。 除此之外，ThreadPoolExecut ...

如图所示，表示发起一个请求时，涉及到数据库的相关操作，在前面的文章中我们说过，如果服务端要提升整体的吞吐量，就必须要减少每一次请求的处理时长，那么在当前这个场景中，数据库层面哪些因素会影响到性能呢？ 图2-1 池化技术，减少频繁创建数据库连接遇到这样的问题，解决办法就是顺着当前整体的逻辑去思考，首先，应用要和数据库打交道，必然会设计到数据库链接的建立。然后在当前连接中完成数据库的相关操作，最后再关闭连接。 在这种场景下，客户端每次发起请求，都需要重新建立连接，如果频繁的创建连接是否会影响到性能呢？答案是一定的，我们通过下面这样一个方式来验证一下 # -i指定网卡名称tcpdump -i eth0 -nn -tttt port 3306 当我们向数据库发起一次连接时，上述抓包命令会打印连接的相关信息如下。（通过Navicat 的链接测试工具测试） 关注前面8行数据即可。 2021-06-24 23:15:50.130812 IP 218.76.8.219.57423 > 172.17.136.216.3306: Flags [S], seq 759743325, win ...

Redis中的多路复用模型Redis6用到了多线程？那多线程应用在哪些地方，引入多线程后，又改如何保证线程安全性呢？同时，如何在性能和线程安全性方面做好平衡？ 关于Redis的单线程模型在Redis6.0之前，我们一直说Redis是单线程，所以并不会存在线程安全问题，而这个单线程，实际上就是在做数据IO处理中，是用的主线程来串行执行，如图4-7所示。 Redis基于Reactor模式设计开发了自己的一套高效事件处理模型，这个事件处理模型对应的就是Redis中的文件事件处理器，这个文件事件处理器是单线程运行的，这也是为什么我们一直强调Redis是线程安全的。 既然Redis是基于Reactor模型实现，那它必然用了I/O多路复用机制来监听多个客户端连接，然后把感兴趣的事件（READ/ACCEPT/CLOSE/WRITE）注册到多路复用器中。 文件事件处理器中使用I/O多路复用模型同时监听多个客户端连接，并且根据当前连接执行的任务类型关联不同的事件处理器（连接应答处理器、命令请求处理器、命令回复处理器）来处理这些事件。 这样设计的好处： 文件事件处理器实现了高性能的网络IO通信模型 通过 ...

在上一篇文章中，详细分析了设计一个千万级并发架构所需要思考的问题，以及解决方案。在这一片文章中，我们主要分析如何在职场足够用户数量的情况下，同步提升架构的性能降低平均响应时间。 如何降低RT的值继续看上面这个图，一个请求只有等到tomcat容器中的应用执行完成才能返回，而请求在执行过程中会做什么事情呢？ 查询数据库 访问磁盘数据 进行内存运算 调用远程服务 这些操作每一个步骤都会消耗时间，当前客户端的请求只有等到这些操作都完成之后才能返回，所以降低RT的方法，就是优化业务逻辑的处理。 数据库瓶颈的优化当18000个请求进入到服务端并且被接收后，开始执行业务逻辑处理，那么必然会查询数据库。 每个请求至少都有一次查询数据库的操作，多的需要查询3~5次以上，我们假设按照3次来计算，那么每秒会对数据库形成54000个请求，假设一台数据库服务器每秒支撑10000个请求（影响数据库的请求数量有很多因素，比如数据库表的数据量、数据库服务器本身的系统性能、查询语句的复杂度），那么需要6台数据库服务器才能支撑每秒10000个请求。 除此之外，数据库层面还有涉及到其他的优化方案。 首先是Mysql的 ...

大家先思考一个问题，这也是在面试过程中经常遇到的问题。 如果你们公司现在的产品能够支持10W用户访问，你们老板突然和你说，融到钱了，会大量投放广告，预计在1个月后用户量会达到1000W，如果这个任务交给你，你应该怎么做？ 1000W用户的问题分解如何支撑1000W用户其实是一个非常抽象的问题，对于技术开发来说，我们需要一个非常明确的对于执行关键业务上的性能指标数据，比如，高峰时段下对于事务的响应时间、并发用户数、QPS、成功率、以及基本指标要求等，这些都 必须要非常明确，只有这样才能够指导整个架构的改造和优化。所以，如果大家接到这样一个问题，首先需要去定位到问题的本质，也就是首先得知道一些可量化的数据指标。 如果有过往的相似业务交易历史数据经验，你需要尽量参考，处理这些收集到的原始数据（日志），从而分析出高峰时段，以及该时段下的交易行为，交易规模等，得到你想要看清楚的需求细节 另外一种情况，就是没有相关的数据指标作为参考，这个时候就需要经验来分析。比如可以参考一些类似行业的比较成熟的业务交易模型（比如银行业的日常交易活动或交通行业售检票交易活动）或者干脆遵循“2/8”原则和“2 ...

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub. Quick StartCreate a new post$ hexo new "My New Post" More info: Writing Run server$ hexo server More info: Server Generate static files$ hexo generate More info: Generating Deploy to remote sites$ hexo deploy More info: Deployment