[Kafka服务器网络延迟优化]的搜索结果

...，本站仅提供文章转载服务，并不拥有其所有权，也不对文章内容的真实性、准确性和合法性承担责任。 如发现本文存在侵权、违法、违规或事实不符的情况，请及时联系我们，我们将第一时间进行核实并删除相应内容。 1、引言 IM等社交应用的开发工作中，乱码问题也很常见，比如: 1）IM聊天消息中的Emoji表情为什么发给后端后MySQL数据库里会乱码； 2）文件名中带有中文的大文件聊天消息发送后，对方看到的文名是乱码； 3）Http rest接口调用时，后端读取到APP端传过来的参数有中文乱码问题； ... ... 那么，对于乱码这个看似不起眼，但并不是一两话能讲清楚的问题，是很有必要从根源了解字符集和编码原理，知其然知其所以然显然是一个优秀码农的基本素养，所以，便有了本文，希望能帮助到你。 推荐阅读：关于字符编码知识的详细讲解请见《字符编码那点事：快速理解ASCII、Unicode、GBK和UTF-8》。 学习交流： - 即时通讯/推送技术开发交流5群：215477170 [推荐] - 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》 （本文同步发布于：http://www.52im.net/thread-2868-1-1.html） 2、关于作者 卢钧轶：爱捣腾Linux的DBA。曾任职于大众点评网DBA团队，主要关注MySQL、Memcache、MMM等产品的高性能和高可用架构。 个人微博：米雪儿侬好的cenalulu Github地址：https://github.com/cenalulu 3、系列文章 本文是IM开发干货系列文章中的第21篇，总目录如下： 《IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递》 《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》 《如何保证IM实时消息的“时序性”与“一致性”？》 《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》 《IM群聊消息如此复杂，如何保证不丢不重？》 《一种Android端IM智能心跳算法的设计与实现探讨（含样例代码）》 《移动端IM登录时拉取数据如何作到省流量？》 《通俗易懂：基于集群的移动端IM接入层负载均衡方案分享》 《浅谈移动端IM的多点登陆和消息漫游原理》 《IM开发基础知识补课(一)：正确理解前置HTTP SSO单点登陆接口的原理》 《IM开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》 《IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》 《IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》 《IM群聊消息的已读回执功能该怎么实现？》 《IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)？》 《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》 《一个低成本确保IM消息时序的方法探讨》 《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》 《IM里“附近的人”功能实现原理是什么？如何高效率地实现它？》 《IM开发基础知识补课(七)：主流移动端账号登录方式的原理及设计思路》 《IM开发基础知识补课(八)：史上最通俗，彻底搞懂字符乱码问题的本质》（本文） 4、正文概述 字符集和编码无疑是IT菜鸟甚至是各种大神的头痛问题。当遇到纷繁复杂的字符集，各种火星文和乱码时，问题的定位往往变得非常困难。 本文内容就将会从原理方面对字符集和编码做个简单的科普介绍，同时也会介绍一些通用的乱码故障定位的方法以方便读者以后能够更从容的定位相关问题。 在正式介绍之前，先做个小申明：如果你希望非常精确的理解各个名词的解释，那么可以详细阅读这篇《字符编码那点事：快速理解ASCII、Unicode、GBK和UTF-8》。 本文是博主通过自己理解消化后并转化成易懂浅显的表述后的介绍，会尽量以简单明了的文字来从要源讲解字符集、字符编码的概念，以及在遭遇乱码时的一些常用诊断技巧，希望能助你对于“乱码”问题有更深地理解。 5、什么是字符集 在介绍字符集之前，我们先了解下为什么要有字符集。 我们在计算机屏幕上看到的是实体化的文字，而在计算机存储介质中存放的实际是二进制的比特流。那么在这两者之间的转换规则就需要一个统一的标准，否则把我们的U盘插到老板的电脑上，文档就乱码了；小伙伴QQ上传过来的文件，在我们本地打开又乱码了。 于是为了实现转换标准，各种字符集标准就出现了。 简单的说：字符集就规定了某个文字对应的二进制数字存放方式（编码）和某串二进制数值代表了哪个文字（解码）的转换关系。 那么为什么会有那么多字符集标准呢？ 这个问题实际非常容易回答。问问自己为什么我们的插头拿到英国就不能用了呢？为什么显示器同时有DVI、VGA、HDMI、DP这么多接口呢？很多规范和标准在最初制定时并不会意识到这将会是以后全球普适的准则，或者处于组织本身利益就想从本质上区别于现有标准。于是，就产生了那么多具有相同效果但又不相互兼容的标准了。 说了那么多我们来看一个实际例子，下面就是“屌”这个字在各种编码下的十六进制和二进制编码结果，怎么样有没有一种很屌的感觉？ 6、什么是字符编码 字符集只是一个规则集合的名字，对应到真实生活中，字符集就是对某种语言的称呼。例如：英语，汉语，日语。 对于一个字符集来说要正确编码转码一个字符需要三个关键元素： 1）字库表（character repertoire）：是一个相当于所有可读或者可显示字符的数据库，字库表决定了整个字符集能够展现表示的所有字符的范围； 2）编码字符集（coded character set）：即用一个编码值code point来表示一个字符在字库中的位置； 3）字符编码（character encoding form）：将编码字符集和实际存储数值之间的转换关系。 一般来说都会直接将code point的值作为编码后的值直接存储。例如在ASCII中“A”在表中排第65位，而编码后A的数值是 0100 0001 也即十进制的65的二进制转换结果。 看到这里，可能很多读者都会有和我当初一样的疑问：字库表和编码字符集看来是必不可少的，那既然字库表中的每一个字符都有一个自己的序号，直接把序号作为存储内容就好了。为什么还要多此一举通过字符编码把序号转换成另外一种存储格式呢？ 其实原因也比较容易理解：统一字库表的目的是为了能够涵盖世界上所有的字符，但实际使用过程中会发现真正用的上的字符相对整个字库表来说比例非常低。例如中文地区的程序几乎不会需要日语字符，而一些英语国家甚至简单的ASCII字库表就能满足基本需求。而如果把每个字符都用字库表中的序号来存储的话，每个字符就需要3个字节（这里以Unicode字库为例），这样对于原本用仅占一个字符的ASCII编码的英语地区国家显然是一个额外成本（存储体积是原来的三倍）。算的直接一些，同样一块硬盘，用ASCII可以存1500篇文章，而用3字节Unicode序号存储只能存500篇。于是就出现了UTF-8这样的变长编码。在UTF-8编码中原本只需要一个字节的ASCII字符，仍然只占一个字节。而像中文及日语这样的复杂字符就需要2个到3个字节来存储。 关于字符编码知识的详细讲解请见：《字符编码那点事：快速理解ASCII、Unicode、GBK和UTF-8》。 7、UTF-8和Unicode的关系 看完上面两个概念解释，那么解释UTF-8和Unicode的关系就比较简单了。 Unicode就是上文中提到的编码字符集，而UTF-8就是字符编码，即Unicode规则字库的一种实现形式。 随着互联网的发展，对同一字库集的要求越来越迫切，Unicode标准也就自然而然的出现。它几乎涵盖了各个国家语言可能出现的符号和文字，并将为他们编号。详见：Unicode百科介绍。 Unicode的编号从 0000 开始一直到10FFFF 共分为17个Plane，每个Plane中有65536个字符。而UTF-8则只实现了第一个Plane，可见UTF-8虽然是一个当今接受度最广的字符集编码，但是它并没有涵盖整个Unicode的字库，这也造成了它在某些场景下对于特殊字符的处理困难（下文会有提到）。 8、UTF-8编码简介 为了更好的理解后面的实际应用，我们这里简单的介绍下UTF-8的编码实现方法。即UTF-8的物理存储和Unicode序号的转换关系。 UTF-8编码为变长编码，最小编码单位（code unit）为一个字节。一个字节的前1-3个bit为描述性部分，后面为实际序号部分： 1）如果一个字节的第一位为0，那么代表当前字符为单字节字符，占用一个字节的空间。0之后的所有部分（7个bit）代表在Unicode中的序号； 2）如果一个字节以110开头，那么代表当前字符为双字节字符，占用2个字节的空间。110之后的所有部分（5个bit）加上后一个字节的除10外的部分（6个bit）代表在Unicode中的序号。且第二个字节以10开头； 3）如果一个字节以1110开头，那么代表当前字符为三字节字符，占用3个字节的空间。110之后的所有部分（5个bit）加上后两个字节的除10外的部分（12个bit）代表在Unicode中的序号。且第二、第三个字节以10开头； 4）如果一个字节以10开头，那么代表当前字节为多字节字符的第二个字节。10之后的所有部分（6个bit）和之前的部分一同组成在Unicode中的序号。 具体每个字节的特征可见下表，其中“x”代表序号部分，把各个字节中的所有x部分拼接在一起就组成了在Unicode字库中的序号。如下图所示。 我们分别看三个从一个字节到三个字节的UTF-8编码例子： 细心的读者不难从以上的简单介绍中得出以下规律： 1）3个字节的UTF-8十六进制编码一定是以E开头的； 2）2个字节的UTF-8十六进制编码一定是以C或D开头的； 3）1个字节的UTF-8十六进制编码一定是以比8小的数字开头的。 9、为什么会出现乱码 乱码也就是英文常说的mojibake（由日语的文字化け音译）。 简单的说乱码的出现是因为：编码和解码时用了不同或者不兼容的字符集。 对应到真实生活中：就好比是一个英国人为了表示祝福在纸上写了bless（编码过程）。而一个法国人拿到了这张纸，由于在法语中bless表示受伤的意思，所以认为他想表达的是受伤（解码过程）。这个就是一个现实生活中的乱码情况。 在计算机科学中一样：一个用UTF-8编码后的字符，用GBK去解码。由于两个字符集的字库表不一样，同一个汉字在两个字符表的位置也不同，最终就会出现乱码。 我们来看一个例子，假设我们用UTF-8编码存储“很屌”两个字，会有如下转换： 于是我们得到了E5BE88E5B18C这么一串数值，而显示时我们用GBK解码进行展示，通过查表我们获得以下信息： 解码后我们就得到了“寰堝睂”这么一个错误的结果，更要命的是连字符个数都变了。 10、如何识别乱码的本来想要表达的文字 要从乱码字符中反解出原来的正确文字需要对各个字符集编码规则有较为深刻的掌握。但是原理很简单，这里用以MySQL数据库中的数据操纵中最常见的UTF-8被错误用GBK展示时的乱码为例，来说明具体反解和识别过程。 10.1 第1步：编码 假设我们在页面上看到“寰堝睂”这样的乱码，而又得知我们的浏览器当前使用GBK编码。那么第一步我们就能先通过GBK把乱码编码成二进制表达式。 当然查表编码效率很低，我们也可以用以下SQL语句直接通过MySQL客户端来做编码工作： mysql [localhost] {msandbox} > selecthex(convert('寰堝睂'using gbk)); +-------------------------------------+ | hex(convert('寰堝睂'using gbk)) | +-------------------------------------+ | E5BE88E5B18C | +-------------------------------------+ 1 row inset(0.01 sec) 10.2 第2步：识别 现在我们得到了解码后的二进制字符串E5BE88E5B18C。然后我们将它按字节拆开。 然后套用之前UTF-8编码介绍章节中总结出的规律，就不难发现这6个字节的数据符合UTF-8编码规则。如果整个数据流都符合这个规则的话，我们就能大胆假设乱码之前的编码字符集是UTF-8。 10.3 第3步：解码 然后我们就能拿着 E5BE88E5B18C 用UTF-8解码，查看乱码前的文字了。 当然我们可以不查表直接通过SQL获得结果： mysql [localhost] {msandbox} ((none)) > selectconvert(0xE5BE88E5B18C using utf8); +------------------------------------+ | convert(0xE5BE88E5B18C using utf8) | +------------------------------------+ | 很屌 | +------------------------------------+ 1 row inset(0.00 sec) 11、常见的IM乱码问题处理之MySQL中的Emoji字符 所谓Emoji就是一种在Unicode位于 \u1F601-\u1F64F 区段的字符。这个显然超过了目前常用的UTF-8字符集的编码范围 \u0000-\uFFFF。Emoji表情随着IOS的普及和微信的支持越来越常见。 下面就是几个常见的Emoji（IM聊天软件中经常会被用到）： 那么Emoji字符表情会对我们平时的开发运维带来什么影响呢？ 最常见的问题就在于将他存入MySQL数据库的时候。一般来说MySQL数据库的默认字符集都会配置成UTF-8（三字节），而utf8mb4在5.5以后才被支持，也很少会有DBA主动将系统默认字符集改成utf8mb4。 那么问题就来了，当我们把一个需要4字节UTF-8编码才能表示的字符存入数据库的时候就会报错：ERROR 1366: Incorrect string value: '\xF0\x9D\x8C\x86' for column 。 如果认真阅读了上面的解释，那么这个报错也就不难看懂了：我们试图将一串Bytes插入到一列中，而这串Bytes的第一个字节是 \xF0 意味着这是一个四字节的UTF-8编码。但是当MySQL表和列字符集配置为UTF-8的时候是无法存储这样的字符的，所以报了错。 那么遇到这种情况我们如何解决呢？ 有两种方式： 1）升级MySQL到5.6或更高版本，并且将表字符集切换至utf8mb4； 2）在把内容存入到数据库之前做一次过滤，将Emoji字符替换成一段特殊的文字编码，然后再存入数据库中。之后从数据库获取或者前端展示时再将这段特殊文字编码转换成Emoji显示。 第二种方法我们假设用 --1F601-- 来替代4字节的Emoji，那么具体实现python代码可以参见Stackoverflow上的回答。 12、参考文献 [1] 如何配置Python默认字符集 [2] 字符编码那点事：快速理解ASCII、Unicode、GBK和UTF-8 [3] Unicode中文编码表 [4] Emoji Unicode Table [5] Every Developer Should Know About The Encoding 附录：更多IM开发方面的文章 [1] IM开发综合文章： 《新手入门一篇就够：从零开发移动端IM》 《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》 《移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结》 《从客户端的角度来谈谈移动端IM的消息可靠性和送达机制》 《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》 《腾讯技术分享：社交网络图片的带宽压缩技术演进之路》 《小白必读：闲话HTTP短连接中的Session和Token》 《IM开发基础知识补课：正确理解前置HTTP SSO单点登陆接口的原理》 《移动端IM开发需要面对的技术问题》 《开发IM是自己设计协议用字节流好还是字符流好？》 《请问有人知道语音留言聊天的主流实现方式吗？》 《一个低成本确保IM消息时序的方法探讨》 《完全自已开发的IM该如何设计“失败重试”机制？》 《通俗易懂：基于集群的移动端IM接入层负载均衡方案分享》 《微信对网络影响的技术试验及分析（论文全文）》 《即时通讯系统的原理、技术和应用（技术论文）》 《开源IM工程“蘑菇街TeamTalk”的现状：一场有始无终的开源秀》 《QQ音乐团队分享：Android中的图片压缩技术详解（上篇）》 《QQ音乐团队分享：Android中的图片压缩技术详解（下篇）》 《腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》 《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（上篇）》 《腾讯原创分享(三)：如何大幅压缩移动网络下APP的流量消耗（下篇）》 《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》 《基于社交网络的Yelp是如何实现海量用户图片的无损压缩的？》 《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》 《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)》 《字符编码那点事：快速理解ASCII、Unicode、GBK和UTF-8》 《全面掌握移动端主流图片格式的特点、性能、调优等》 《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》 《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》 《自已开发IM有那么难吗？手把手教你自撸一个Andriod版简易IM (有源码)》 《融云技术分享：解密融云IM产品的聊天消息ID生成策略》 《适合新手：从零开发一个IM服务端（基于Netty，有完整源码）》 《拿起键盘就是干：跟我一起徒手开发一套分布式IM系统》 >> 更多同类文章 …… [2] 有关IM架构设计的文章： 《浅谈IM系统的架构设计》 《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》 《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》 《一套原创分布式即时通讯(IM)系统理论架构方案》 《从零到卓越：京东客服即时通讯系统的技术架构演进历程》 《蘑菇街即时通讯/IM服务器开发之架构选择》 《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》 《微信后台基于时间序的海量数据冷热分级架构设计实践》 《微信技术总监谈架构：微信之道——大道至简(演讲全文)》 《如何解读《微信技术总监谈架构：微信之道——大道至简》》 《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》 《17年的实践：腾讯海量产品的技术方法论》 《移动端IM中大规模群消息的推送如何保证效率、实时性？》 《现代IM系统中聊天消息的同步和存储方案探讨》 《IM开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》 《IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》 《IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》 《WhatsApp技术实践分享：32人工程团队创造的技术神话》 《微信朋友圈千亿访问量背后的技术挑战和实践总结》 《王者荣耀2亿用户量的背后：产品定位、技术架构、网络方案等》 《IM系统的MQ消息中间件选型：Kafka还是RabbitMQ？》 《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》 《以微博类应用场景为例，总结海量社交系统的架构设计步骤》 《快速理解高性能HTTP服务端的负载均衡技术原理》 《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》 《知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路》 《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》 《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》 《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》 《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》 《一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践》 《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》 《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》 《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》 《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》 《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》 《社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》 《社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》 《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》 《社交软件红包技术解密(七)：支付宝红包的海量高并发技术实践》 《社交软件红包技术解密(八)：全面解密微博红包技术方案》 《社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等》 《即时通讯新手入门：一文读懂什么是Nginx？它能否实现IM的负载均衡？》 《即时通讯新手入门：快速理解RPC技术——基本概念、原理和用途》 《多维度对比5款主流分布式MQ消息队列，妈妈再也不担心我的技术选型了》 《从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路》 《从游击队到正规军(二)：马蜂窝旅游网的IM客户端架构演进和实践总结》 《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》 《瓜子IM智能客服系统的数据架构设计（整理自现场演讲，有配套PPT）》 《阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处》 >> 更多同类文章 …… （本文同步发布于：http://www.52im.net/thread-2868-1-1.html） 本篇文章为转载内容。原文链接：https://blog.csdn.net/hellojackjiang2011/article/details/103586305。 该文由互联网用户投稿提供，文中观点代表作者本人意见，并不代表本站的立场。 作为信息平台，本站仅提供文章转载服务，并不拥有其所有权，也不对文章内容的真实性、准确性和合法性承担责任。 如发现本文存在侵权、违法、违规或事实不符的情况，请及时联系我们，我们将第一时间进行核实并删除相应内容。

...，本站仅提供文章转载服务，并不拥有其所有权，也不对文章内容的真实性、准确性和合法性承担责任。 如发现本文存在侵权、违法、违规或事实不符的情况，请及时联系我们，我们将第一时间进行核实并删除相应内容。 浅谈 前段时间有个客户问我，为啥你们项目都搞了好几年了，为啥线上还会经常反馈卡顿，呃呃呃。。 于是根据自己的理解以及网上大佬们的思路总结了一篇关于卡顿优化这块的文章。 卡顿问题是一个老生常谈的话题了，一个App的好坏，卡顿也许会占一半，它直接决定了用户的留存问题，各大app排行版上，那些知名度较高，但是排行较低的，可能就要思考思考是不是和你app本身有关系了。 卡顿一直是性能优化中相对重要的一个点，因为其涉及了UI绘制、垃圾回收(GC)、线程调度以及Binder，CPU，GPU方面等JVM以及FrameWork相关知识 如果能做好卡顿优化，那么也就间接证明你对Android FrameWork的理解之深。 接下来我们就来讲解下卡顿方面的知识。 什么是卡顿： 对用户来讲就是界面不流畅，滞顿。 场景如下： 1.视频加载慢，画面卡顿，卡死，黑屏 2.声音卡顿，音画不同步。 3.动画帧卡顿，交互响应慢 4.滑动不跟手，列表自动更新，滚动不流畅 5.网络响应慢，数据和画面展示慢、 6.过渡动画生硬。 7.界面不可交互，卡死，等等现象。 卡顿是如何发生的 卡顿产生的原因一般都比较复杂，如CPU内存大小，IO操作，锁操作，低效的算法等都会引起卡顿。 站在开发的角度看： 通常我们讲，屏幕刷新率是60fps，需要在16ms内完成所有的工作才不会造成卡顿。 为什么是16ms，不是17，18呢？ 下面我们先来理清在UI绘制中的几个概念： SurfaceFlinger： SurfaceFlinger作用是接受多个来源的图形显示数据Surface，合成后发送到显示设备,比如我们的主界面中：可能会有statusBar，侧滑菜单，主界面，这些View都是独立Surface渲染和更新，最后提交给SF后，SF根据Zorder，透明度，大小，位置等参数，合成为一个数据buffer，传递HWComposer或者OpenGL处理，最终给显示器。 在显示过程中使用到了bufferqueue，surfaceflinger作为consumer方，比如windowmanager管理的surface作为生产方产生页面，交由surfaceflinger进行合成。 VSYNC Android系统每隔16ms发出VSYNC信号，触发对UI进行渲染，VSYNC是一种在PC上很早就有应用，可以理解为一种定时中断技术。 tearing 问题： 早期的 Android 是没有 vsync 机制的，CPU 和 GPU 的配合也比较混乱，这也造成著名的 tearing 问题，即 CPU/GPU 直接更新正在显示的屏幕 buffer 造成画面撕裂。 后续 Android 引入了双缓冲机制，但是 buffer 的切换也需要一个比较合适的时机，也就是屏幕扫描完上一帧后的时机，这也就是引入 vsync 的原因。 早先一般的屏幕刷新率是 60fps，所以每个 vsync 信号的间隔也是 16ms，不过随着技术的更迭以及厂商对于流畅性的追求，越来越多 90fps 和 120fps 的手机面世，相对应的间隔也就变成了 11ms 和 8ms。 VSYNC信号种类： 1.屏幕产生的硬件VSYNC：硬件VSYNC是一种脉冲信号，起到开关和触发某种操作的作用。 2.由SurfaceFlinger将其转成的软件VSYNC信号，经由Binder传递给Choreographer Choreographer： 编舞者，用于注册VSYNC信号并接收VSYNC信号回调，当内部接收到这个信号时最终会调用到doFrame进行帧的绘制操作。 Choreographer在系统中流程： 如何通过Choreographer计算掉帧情况：原理就是: 通过给Choreographer设置FrameCallback，在每次绘制前后看时间差是16.6ms的多少倍，即为前后掉帧率。 使用方式如下： //Application.javapublic void onCreate() {super.onCreate();//在Application中使用postFrameCallbackChoreographer.getInstance().postFrameCallback(new FPSFrameCallback(System.nanoTime()));}public class FPSFrameCallback implements Choreographer.FrameCallback {private static final String TAG = "FPS_TEST";private long mLastFrameTimeNanos = 0;private long mFrameIntervalNanos;public FPSFrameCallback(long lastFrameTimeNanos) {mLastFrameTimeNanos = lastFrameTimeNanos;mFrameIntervalNanos = (long)(1000000000 / 60.0);}@Overridepublic void doFrame(long frameTimeNanos) {//初始化时间if (mLastFrameTimeNanos == 0) {mLastFrameTimeNanos = frameTimeNanos;}final long jitterNanos = frameTimeNanos - mLastFrameTimeNanos;if (jitterNanos >= mFrameIntervalNanos) {final long skippedFrames = jitterNanos / mFrameIntervalNanos;if(skippedFrames>30){//丢帧30以上打印日志Log.i(TAG, "Skipped " + skippedFrames + " frames! "+ "The application may be doing too much work on its main thread.");} }mLastFrameTimeNanos=frameTimeNanos;//注册下一帧回调Choreographer.getInstance().postFrameCallback(this);} } UI绘制全路径分析： 有了前面几个概念，这里我们让SurfaceFlinger结合View的绘制流程用一张图来表达整个绘制流程： 生产者：APP方构建Surface的过程。 消费者：SurfaceFlinger UI绘制全路径分析卡顿原因： 接下来，我们逐个分析，看看都会有哪些原因可能造成卡顿： 1.渲染流程 1.Vsync 调度：这个是起始点，但是调度的过程会经过线程切换以及一些委派的逻辑，有可能造成卡顿，但是一般可能性比较小，我们也基本无法介入； 2.消息调度：主要是 doframe Message 的调度，这就是一个普通的 Handler 调度，如果这个调度被其他的 Message 阻塞产生了时延，会直接导致后续的所有流程不会被触发 3.input 处理：input 是一次 Vsync 调度最先执行的逻辑，主要处理 input 事件。如果有大量的事件堆积或者在事件分发逻辑中加入大量耗时业务逻辑，会造成当前帧的时长被拉大，造成卡顿，可以尝试通过事件采样的方案，减少 event 的处理 4.动画处理：主要是 animator 动画的更新，同理，动画数量过多，或者动画的更新中有比较耗时的逻辑，也会造成当前帧的渲染卡顿。对动画的降帧和降复杂度其实解决的就是这个问题； 5.view 处理：主要是接下来的三大流程，过度绘制、频繁刷新、复杂的视图效果都是此处造成卡顿的主要原因。比如我们平时所说的降低页面层级，主要解决的就是这个问题； 6.measure/layout/draw：view 渲染的三大流程，因为涉及到遍历和高频执行，所以这里涉及到的耗时问题均会被放大，比如我们会降不能在 draw 里面调用耗时函数，不能 new 对象等等； 7.DisplayList 的更新：这里主要是 canvas 和 displaylist 的映射，一般不会存在卡顿问题，反而可能存在映射失败导致的显示问题； 8.OpenGL 指令转换：这里主要是将 canvas 的命令转换为 OpenGL 的指令，一般不存在问题 9.buffer 交换：这里主要指 OpenGL 指令集交换给 GPU，这个一般和指令的复杂度有关 10.GPU 处理：顾名思义，这里是 GPU 对数据的处理，耗时主要和任务量和纹理复杂度有关。这也就是我们降低 GPU 负载有助于降低卡顿的原因； 11.layer 合成：Android P 修改了 Layer 的计算方法 , 把这部分放到了 SurfaceFlinger 主线程去执行, 如果后台 Layer 过多, 就会导致 SurfaceFlinger 在执行 rebuildLayerStacks 的时候耗时 , 导致 SurfaceFlinger 主线程执行时间过长。 可以选择降低Surface层级来优化卡顿。 12.光栅化/Display：这里暂时忽略，底层系统行为； Buffer 切换：主要是屏幕的显示，这里 buffer 的数量也会影响帧的整体延迟，不过是系统行为，不能干预。 2.系统负载 内存：内存的吃紧会直接导致 GC 的增加甚至 ANR，是造成卡顿的一个不可忽视的因素； CPU：CPU 对卡顿的影响主要在于线程调度慢、任务执行的慢和资源竞争，比如 1.降频会直接导致应用卡顿； 2.后台活动进程太多导致系统繁忙，cpu \ io \ memory 等资源都会被占用, 这时候很容易出现卡顿问题 ，这种情况比较常见,可以使用dumpsys cpuinfo查看当前设备的cpu使用情况： 3.主线程调度不到 , 处于 Runnable 状态，这种情况比较少见 4.System 锁：system_server 的 AMS 锁和 WMS 锁 , 在系统异常的情况下 , 会变得非常严重 , 如下图所示 , 许多系统的关键任务都被阻塞 , 等待锁的释放 , 这时候如果有 App 发来的 Binder 请求带锁 , 那么也会进入等待状态 , 这时候 App 就会产生性能问题 ; 如果此时做 Window 动画 , 那么 system_server 的这些锁也会导致窗口动画卡顿 GPU：GPU 的影响见渲染流程，但是其实还会间接影响到功耗和发热； 功耗/发热：功耗和发热一般是不分家的，高功耗会引起高发热，进而会引起系统保护，比如降频、热缓解等，间接的导致卡顿。 如何监控卡顿 线下监控： 我们知道卡顿问题的原因错综复杂，但最终都可以反馈到CPU使用率上来 1.使用dumpsys cpuinfo命令 这个命令可以获取当时设备cpu使用情况，我们可以在线下通过重度使用应用来检测可能存在的卡顿点 A8S:/ $ dumpsys cpuinfoLoad: 1.12 / 1.12 / 1.09CPU usage from 484321ms to 184247ms ago (2022-11-02 14:48:30.793 to 2022-11-02 14:53:30.866):2% 1053/scanserver: 0.2% user + 1.7% kernel0.6% 934/system_server: 0.4% user + 0.1% kernel / faults: 563 minor0.4% 564/signserver: 0% user + 0.4% kernel0.2% 256/ueventd: 0.1% user + 0% kernel / faults: 320 minor0.2% 474/surfaceflinger: 0.1% user + 0.1% kernel0.1% 576/vendor.sprd.hardware.gnss@2.0-service: 0.1% user + 0% kernel / faults: 54 minor0.1% 286/logd: 0% user + 0% kernel / faults: 10 minor0.1% 2821/com.allinpay.appstore: 0.1% user + 0% kernel / faults: 1312 minor0.1% 447/android.hardware.health@2.0-service: 0% user + 0% kernel / faults: 1175 minor0% 1855/com.smartpos.dataacqservice: 0% user + 0% kernel / faults: 755 minor0% 2875/com.allinpay.appstore:pushcore: 0% user + 0% kernel / faults: 744 minor0% 1191/com.android.systemui: 0% user + 0% kernel / faults: 70 minor0% 1774/com.android.nfc: 0% user + 0% kernel0% 172/kworker/1:2: 0% user + 0% kernel0% 145/irq/24-70900000: 0% user + 0% kernel0% 575/thermald: 0% user + 0% kernel / faults: 300 minor... 2.CPU Profiler 这个工具是AS自带的CPU性能检测工具，可以在PC上实时查看我们CPU使用情况。 AS提供了四种Profiling Model配置： 1.Sample Java Methods：在应用程序基于Java的代码执行过程中，频繁捕获应用程序的调用堆栈 获取有关应用程序基于Java的代码执行的时间和资源使用情况信息。 2.Trace java methods：在运行时对应用程序进行检测，以在每个方法调用的开始和结束时记录时间戳。收集时间戳并进行比较以生成方法跟踪数据，包括时序信息和CPU使用率。 请注意与检测每种方法相关的开销会影响运行时性能，并可能影响性能分析数据。对于生命周期相对较短的方法，这一点甚至更为明显。此外，如果您的应用在短时间内执行大量方法，则探查器可能会很快超过其文件大小限制，并且可能无法记录任何进一步的跟踪数据。 3.Sample C/C++ Functions:捕获应用程序本机线程的示例跟踪。要使用此配置，您必须将应用程序部署到运行Android 8.0（API级别26）或更高版本的设备。 4.Trace System Calls:捕获细粒度的详细信息，使您可以检查应用程序与系统资源的交互方式 您可以检查线程状态的确切时间和持续时间，可视化CPU瓶颈在所有内核中的位置，并添加自定义跟踪事件进行分析。在对性能问题进行故障排除时，此类信息可能至关重要。要使用此配置，您必须将应用程序部署到运行Android 7.0（API级别24）或更高版本的设备。 使用方式： Debug.startMethodTracing("");// 需要检测的代码片段...Debug.stopMethodTracing(); 优点：有比较全面的调用栈以及图像化方法时间显示，包含所有线程的情况 缺点：本身也会带来一点的性能开销，可能会带偏优化方向 火焰图：可以显示当前应用的方法堆栈： 3.Systrace Systrace在前面一篇分析启动优化的文章讲解过 这里我们简单来复习下： Systrace用来记录当前应用的系统以及应用(使用Trace类打点)的各阶段耗时信息包括绘制信息以及CPU信息等。 使用方式： Trace.beginSection("MyApp.onCreate_1");alt(200);Trace.endSection(); 在命令行中： python systrace.py -t 5 sched gfx view wm am app webview -a "com.chinaebipay.thirdcall" -o D:\trac1.html 记录的方法以及CPU中的耗时情况： 优点： 1.轻量级，开销小，CPU使用率可以直观反映 2.右侧的Alerts能够根据我们应用的问题给出具体的建议，比如说，它会告诉我们App界面的绘制比较慢或者GC比较频繁。 4.StrictModel StrictModel是Android提供的一种运行时检测机制，用来帮助开发者自动检测代码中不规范的地方。 主要和两部分相关： 1.线程相关 2.虚拟机相关 基础代码： private void initStrictMode() {// 1、设置Debug标志位，仅仅在线下环境才使用StrictModeif (DEV_MODE) {// 2、设置线程策略StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder().detectCustomSlowCalls() //API等级11，使用StrictMode.noteSlowCode.detectDiskReads().detectDiskWrites().detectNetwork() // or .detectAll() for all detectable problems.penaltyLog() //在Logcat 中打印违规异常信息// .penaltyDialog() //也可以直接跳出警报dialog// .penaltyDeath() //或者直接崩溃.build());// 3、设置虚拟机策略StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder().detectLeakedSqlLiteObjects()// 给NewsItem对象的实例数量限制为1.setClassInstanceLimit(NewsItem.class, 1).detectLeakedClosableObjects() //API等级11.penaltyLog().build());} } 线上监控： 线上需要自动化的卡顿检测方案来定位卡顿，它能记录卡顿发生时的场景。 自动化监控原理： 采用拦截消息调度流程，在消息执行前埋点计时，当耗时超过阈值时，则认为是一次卡顿，会进行堆栈抓取和上报工作 首先，我们看下Looper用于执行消息循环的loop()方法，关键代码如下所示： / Run the message queue in this thread. Be sure to call {@link quit()} to end the loop./public static void loop() {...for (;;) {Message msg = queue.next(); // might blockif (msg == null) {// No message indicates that the message queue is quitting.return;// This must be in a local variable, in case a UI event sets the loggerfinal Printer logging = me.mLogging;if (logging != null) {// 1logging.println(">>>>> Dispatching to " + msg.target + " " +msg.callback + ": " + msg.what);}...try {// 2 msg.target.dispatchMessage(msg);dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0;} finally {if (traceTag != 0) {Trace.traceEnd(traceTag);} }...if (logging != null) {// 3logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);} 在Looper的loop()方法中，在其执行每一个消息（注释2处）的前后都由logging进行了一次打印输出。可以看到，在执行消息前是输出的">>>>> Dispatching to “，在执行消息后是输出的”<<<<< Finished to ",它们打印的日志是不一样的，我们就可以由此来判断消息执行的前后时间点。 具体的实现可以归纳为如下步骤： 1、首先，我们需要使用Looper.getMainLooper().setMessageLogging()去设置我们自己的Printer实现类去打印输出logging。这样，在每个message执行的之前和之后都会调用我们设置的这个Printer实现类。 2、如果我们匹配到">>>>> Dispatching to "之后，我们就可以执行一行代码：也就是在指定的时间阈值之后，我们在子线程去执行一个任务，这个任务就是去获取当前主线程的堆栈信息以及当前的一些场景信息，比如：内存大小、电脑、网络状态等。 3、如果在指定的阈值之内匹配到了"<<<<< Finished to "，那么说明message就被执行完成了，则表明此时没有产生我们认为的卡顿效果，那我们就可以将这个子线程任务取消掉。 这里我们使用blockcanary来做测试: BlockCanary APM是一个非侵入式的性能监控组件，可以通过通知的形式弹出卡顿信息。它的原理就是我们刚刚讲述到的卡顿监控的实现原理。 使用方式： 1.导入依赖 implementation 'com.github.markzhai:blockcanary-android:1.5.0' Application的onCreate方法中开启卡顿监控 // 注意在主进程初始化调用BlockCanary.install(this, new AppBlockCanaryContext()).start(); 3.继承BlockCanaryContext类去实现自己的监控配置上下文类 public class AppBlockCanaryContext extends BlockCanaryContext {....../ 指定判定为卡顿的阈值threshold (in millis), 你可以根据不同设备的性能去指定不同的阈值 @return threshold in mills/public int provideBlockThreshold() {return 1000;}....} 4.在Activity的onCreate方法中执行一个耗时操作 try {Thread.sleep(4000);} catch (InterruptedException e) {e.printStackTrace();} 5.结果： 可以看到一个和LeakCanary一样效果的阻塞可视化堆栈图 那有了BlockCanary的方法耗时监控方式是不是就可以解百愁了呢，呵呵。有那么容易就好了 根据原理：我们拿到的是msg执行前后的时间和堆栈信息，如果msg中有几百上千个方法，就无法确认到底是哪个方法导致的耗时，也有可能是多个方法堆积导致。 这就导致我们无法准确定位哪个方法是最耗时的。如图中：堆栈信息是T2的，而发生耗时的方法可能是T1到T2中任何一个方法甚至是堆积导致。 那如何优化这块？ 这里我们采用字节跳动给我们提供的一个方案：基于 Sliver trace 的卡顿监控体系 Sliver trace 整体流程图： 主要包含两个方面: 检测方案： 在监控卡顿时，首先需要打开 Sliver 的 trace 记录能力，Sliver 采样记录 trace 执行信息，对抓取到的堆栈进行 diff 聚合和缓存。 同时基于我们的需要设置相应的卡顿阈值，以 Message 的执行耗时为衡量。对主线程消息调度流程进行拦截，在消息开始分发执行时埋点，在消息执行结束时计算消息执行耗时，当消息执行耗时超过阈值，则认为产生了一次卡顿。 堆栈聚合策略： 当卡顿发生时，我们需要为此次卡顿准备数据，这部分工作是在端上子线程中完成的，主要是 dump trace 到文件以及过滤聚合要上报的堆栈。分为以下几步： 1.拿到缓存的主线程 trace 信息并 dump 到文件中。 2.然后从文件中读取 trace 信息，按照数据格式，从最近的方法栈向上追溯，找到当前 Message 包含的全部 trace 信息，并将当前 Message 的完整 trace 写入到待上传的 trace 文件中，删除其余 trace 信息。 3.遍历当前 Message trace，按照（Method 执行耗时 > Method 耗时阈值 & Method 耗时为该层堆栈中最耗时）为条件过滤出每一层函数调用堆栈的最长耗时函数，构成最后要上报的堆栈链路，这样特征堆栈中的每一步都是最耗时的，且最底层 Method 为最后的耗时大于阈值的 Method。 之后，将 trace 文件和堆栈一同上报，这样的特征堆栈提取策略保证了堆栈聚合的可靠性和准确性，保证了上报到平台后堆栈的正确合理聚合，同时提供了进一步分析问题的 trace 文件。 可以看到字节给的是一整套监控方案，和前面BlockCanary不同之处就在于，其是定时存储堆栈，缓存，然后使用diff去重的方式，并上传到服务器，可以最大限度的监控到可能发生比较耗时的方法。 开发中哪些习惯会影响卡顿的发生 1.布局太乱，层级太深。 1.1：通过减少冗余或者嵌套布局来降低视图层次结构。比如使用约束布局代替线性布局和相对布局。 1.2：用 ViewStub 替代在启动过程中不需要显示的 UI 控件。 1.3：使用自定义 View 替代复杂的 View 叠加。 2.主线程耗时操作 2.1：主线程中不要直接操作数据库，数据库的操作应该放在数据库线程中完成。 2.2：sharepreference尽量使用apply，少使用commit，可以使用MMKV框架来代替sharepreference。 2.3：网络请求回来的数据解析尽量放在子线程中，不要在主线程中进行复制的数据解析操作。 2.4：不要在activity的onResume和onCreate中进行耗时操作，比如大量的计算等。 2.5：不要在 draw 里面调用耗时函数，不能 new 对象 3.过度绘制 过度绘制是同一个像素点上被多次绘制，减少过度绘制一般减少布局背景叠加等方式，如下图所示右边是过度绘制的图片。 4.列表 RecyclerView使用优化，使用DiffUtil和notifyItemDataSetChanged进行局部更新等。 5.对象分配和回收优化 自从Android引入 ART 并且在Android 5.0上成为默认的运行时之后，对象分配和垃圾回收（GC）造成的卡顿已经显著降低了，但是由于对象分配和GC有额外的开销，它依然又可能使线程负载过重。 在一个调用不频繁的地方（比如按钮点击）分配对象是没有问题的，但如果在在一个被频繁调用的紧密的循环里，就需要避免对象分配来降低GC的压力。 减少小对象的频繁分配和回收操作。 好了，关于卡顿优化的问题就讲到这里，下篇文章会对卡顿中的ANR情况的处理，这里做个铺垫。 如果喜欢我的文章，欢迎关注我的公众号。 点击这看原文链接： 参考 Android卡顿检测及优化 一文读懂直播卡顿优化那些事儿 “终于懂了” 系列：Android屏幕刷新机制—VSync、Choreographer 全面理解！ 深入探索Android卡顿优化（上） 西瓜卡顿 & ANR 优化治理及监控体系建设 5376)] 参考 Android卡顿检测及优化 一文读懂直播卡顿优化那些事儿 “终于懂了” 系列：Android屏幕刷新机制—VSync、Choreographer 全面理解！ 深入探索Android卡顿优化（上） 西瓜卡顿 & ANR 优化治理及监控体系建设 本篇文章为转载内容。原文链接：https://blog.csdn.net/yuhaibing111/article/details/127682399。 该文由互联网用户投稿提供，文中观点代表作者本人意见，并不代表本站的立场。 作为信息平台，本站仅提供文章转载服务，并不拥有其所有权，也不对文章内容的真实性、准确性和合法性承担责任。 如发现本文存在侵权、违法、违规或事实不符的情况，请及时联系我们，我们将第一时间进行核实并删除相应内容。

...，本站仅提供文章转载服务，并不拥有其所有权，也不对文章内容的真实性、准确性和合法性承担责任。 如发现本文存在侵权、违法、违规或事实不符的情况，请及时联系我们，我们将第一时间进行核实并删除相应内容。 1、发布订阅模式 1.1 列表的局限 通过队列的 rpush 和 lpop 可以实现消息队列(队尾进队头出)，但是消费者需要不停地调用 lpop 查看 List 中是否有等待处理的消息(比如写一个 while 循环)。 为了减少通信的消耗，可以 sleep()一段时间再消费，但是会有两个问题: 1、如果生产者生产消息的速度远大于消费者消费消息的速度，List 会占用大量的内存。 2、消息的实时性降低。 list 还提供了一个阻塞的命令:blpop，没有任何元素可以弹出的时候，连接会被阻塞。 基于 list 实现的消息队列，不支持一对多的消息分发。 1.2 发布订阅模式 除了通过 list 实现消息队列之外，Redis 还提供了一组命令实现发布/订阅模式。 这种方式，发送者和接收者没有直接关联(实现了解耦)，接收者也不需要持续尝试获取消息。 1.2.1 订阅频道 首先，我们有很多的频道(channel)，我们也可以把这个频道理解成 queue。订阅者可以订阅一个或者多个频道。消息的发布者(生产者)可以给指定的频道发布消息。只要有消息到达了频道，所有订阅了这个频道的订阅者都会收到这条消息。 需要注意的注意是，发出去的消息不会被持久化，因为它已经从队列里面移除了，所以消费者只能收到它开始订阅这个频道之后发布的消息。 下面我们来看一下发布订阅命令的使用方法。 订阅者订阅频道：可以一次订阅多个，比如这个客户端订阅了 3 个频道。 subscribe channel-1 channel-2 channel-3 发布者可以向指定频道发布消息(并不支持一次向多个频道发送消息): publish channel-1 2673 取消订阅(不能在订阅状态下使用): unsubscribe channel-1 1.2.2 按规则(Pattern)订阅频道 支持 ?和 占位符。? 代表一个字符， 代表 0 个或者多个字符。 消费端 1，关注运动信息: psubscribe sport 消费端 2，关注所有新闻: psubscribe news 消费端 3，关注天气新闻: psubscribe news-weather 生产者，发布 3 条信息 publish news-sport yaoming publish news-music jaychou publish news-weather rain 2、Redis 事务 2.1 为什么要用事务 我们知道 Redis 的单个命令是原子性的(比如 get set mget mset)，如果涉及到多个命令的时候，需要把多个命令作为一个不可分割的处理序列，就需要用到事务。 例如我们之前说的用 setnx 实现分布式锁，我们先 set，然后设置对 key 设置 expire， 防止 del 发生异常的时候锁不会被释放，业务处理完了以后再 del，这三个动作我们就希望它们作为一组命令执行。 Redis 的事务有两个特点: 1、按进入队列的顺序执行。 2、不会受到其他客户端的请求的影响。 Redis 的事务涉及到四个命令:multi(开启事务)，exec(执行事务)，discard (取消事务)，watch(监视) 2.2 事务的用法 案例场景:tom 和 mic 各有 1000 元，tom 需要向 mic 转账 100 元。tom 的账户余额减少 100 元，mic 的账户余额增加 100 元。 通过 multi 的命令开启事务。事务不能嵌套，多个 multi 命令效果一样。 multi 执行后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即被执行，而是被放到一个队列中，当 exec 命令被调用时，所有队列中的命令才会被执行。 通过 exec 的命令执行事务。如果没有执行 exec，所有的命令都不会被执行。如果中途不想执行事务了，怎么办? 可以调用 discard 可以清空事务队列，放弃执行。 2.3 watch命令 在 Redis 中还提供了一个 watch 命令。 它可以为 Redis 事务提供 CAS 乐观锁行为(Check and Set / Compare and Swap)，也就是多个线程更新变量的时候，会跟原值做比较，只有它没有被其他线程修改的情况下，才更新成新的值。 我们可以用 watch 监视一个或者多个 key，如果开启事务之后，至少有一个被监视 key 键在 exec 执行之前被修改了，那么整个事务都会被取消(key 提前过期除外)。可以用 unwatch 取消。 2.4 事务可能遇到的问题 我们把事务执行遇到的问题分成两种，一种是在执行 exec 之前发生错误，一种是在执行 exec 之后发生错误。 2.4.1 在执行 exec 之前发生错误 比如：入队的命令存在语法错误，包括参数数量，参数名等等(编译器错误)。 在这种情况下事务会被拒绝执行，也就是队列中所有的命令都不会得到执行。 2.4.2 在执行 exec 之后发生错误 比如，类型错误，比如对 String 使用了 Hash 的命令，这是一种运行时错误。 最后我们发现 set k1 1 的命令是成功的，也就是在这种发生了运行时异常的情况下， 只有错误的命令没有被执行，但是其他命令没有受到影响。 这个显然不符合我们对原子性的定义，也就是我们没办法用 Redis 的这种事务机制来实现原子性，保证数据的一致。 3、Lua脚本 Lua/ˈluə/是一种轻量级脚本语言，它是用 C 语言编写的，跟数据的存储过程有点类似。 使用 Lua 脚本来执行 Redis 命令的好处: 1、一次发送多个命令，减少网络开销。 2、Redis 会将整个脚本作为一个整体执行，不会被其他请求打断，保持原子性。 3、对于复杂的组合命令，我们可以放在文件中，可以实现程序之间的命令集复用。 3.1 在Redis中调用Lua脚本 使用 eval /ɪ’væl/ 方法，语法格式: redis> eval lua-script key-num [key1 key2 key3 ....] [value1 value2 value3 ....] eval代表执行Lua语言的命令。 lua-script代表Lua语言脚本内容。 key-num表示参数中有多少个key，需要注意的是Redis中key是从1开始的，如果没有key的参数，那么写0。 [key1key2key3…]是key作为参数传递给Lua语言，也可以不填，但是需要和key-num的个数对应起来。 [value1 value2 value3 …]这些参数传递给 Lua 语言，它们是可填可不填的。 示例，返回一个字符串，0 个参数: redis> eval "return 'Hello World'" 0 3.2 在Lua脚本中调用Redis命令 使用 redis.call(command, key [param1, param2…])进行操作。语法格式: redis> eval "redis.call('set',KEYS[1],ARGV[1])" 1 lua-key lua-value command是命令，包括set、get、del等。 key是被操作的键。 param1,param2…代表给key的参数。 注意跟 Java 不一样，定义只有形参，调用只有实参。 Lua 是在调用时用 key 表示形参，argv 表示参数值(实参)。 3.2.1 设置键值对 在 Redis 中调用 Lua 脚本执行 Redis 命令 redis> eval "return redis.call('set',KEYS[1],ARGV[1])" 1 gupao 2673 redis> get gupao 以上命令等价于 set gupao 2673。 在 redis-cli 中直接写 Lua 脚本不够方便，也不能实现编辑和复用，通常我们会把脚本放在文件里面，然后执行这个文件。 3.2.2 在 Redis 中调用 Lua 脚本文件中的命令，操作 Redis 创建 Lua 脚本文件: cd /usr/local/soft/redis5.0.5/src vim gupao.lua Lua 脚本内容，先设置，再取值: cd /usr/local/soft/redis5.0.5/src redis-cli --eval gupao.lua 0 得到返回值: root@localhost src] redis-cli --eval gupao.lua 0 "lua666" 3.2.3 案例:对 IP 进行限流 需求：在 X 秒内只能访问 Y 次。 设计思路：用 key 记录 IP，用 value 记录访问次数。 拿到 IP 以后，对 IP+1。如果是第一次访问，对 key 设置过期时间(参数 1)。否则判断次数，超过限定的次数(参数 2)，返回 0。如果没有超过次数则返回 1。超过时间， key 过期之后，可以再次访问。 KEY[1]是 IP， ARGV[1]是过期时间 X，ARGV[2]是限制访问的次数 Y。 -- ip_limit.lua-- IP 限流，对某个 IP 频率进行限制 ，6 秒钟访问 10 次 local num=redis.call('incr',KEYS[1])if tonumber(num)==1 thenredis.call('expire',KEYS[1],ARGV[1])return 1elseif tonumber(num)>tonumber(ARGV[2]) thenreturn 0 elsereturn 1 end 6 秒钟内限制访问 10 次，调用测试(连续调用 10 次): ./redis-cli --eval "ip_limit.lua" app:ip:limit:192.168.8.111 , 6 10 app:ip:limit:192.168.8.111 是 key 值 ，后面是参数值，中间要加上一个空格和一个逗号，再加上一个空格 。 即:./redis-cli –eval [lua 脚本] [key…]空格,空格[args…] 多个参数之间用一个空格分割 。 代码:LuaTest.java 3.2.4 缓存 Lua 脚本 为什么要缓存 在脚本比较长的情况下，如果每次调用脚本都需要把整个脚本传给 Redis 服务端， 会产生比较大的网络开销。为了解决这个问题，Redis 提供了 EVALSHA 命令，允许开发者通过脚本内容的 SHA1 摘要来执行脚本。 如何缓存 Redis 在执行 script load 命令时会计算脚本的 SHA1 摘要并记录在脚本缓存中，执行 EVALSHA 命令时 Redis 会根据提供的摘要从脚本缓存中查找对应的脚本内容，如果找到了则执行脚本，否则会返回错误:“NOSCRIPT No matching script. Please use EVAL.” 127.0.0.1:6379> script load "return 'Hello World'" "470877a599ac74fbfda41caa908de682c5fc7d4b"127.0.0.1:6379> evalsha "470877a599ac74fbfda41caa908de682c5fc7d4b" 0 "Hello World" 3.2.5 自乘案例 Redis 有 incrby 这样的自增命令，但是没有自乘，比如乘以 3，乘以 5。我们可以写一个自乘的运算，让它乘以后面的参数： local curVal = redis.call("get", KEYS[1]) if curVal == false thencurVal = 0 elsecurVal = tonumber(curVal)endcurVal = curVal tonumber(ARGV[1]) redis.call("set", KEYS[1], curVal) return curVal 把这个脚本变成单行，语句之间使用分号隔开 local curVal = redis.call("get", KEYS[1]); if curVal == false then curVal = 0 else curVal = tonumber(curVal) end; curVal = curVal tonumber(ARGV[1]); redis.call("set", KEYS[1], curVal); return curVal script load ‘命令’ 127.0.0.1:6379> script load 'local curVal = redis.call("get", KEYS[1]); if curVal == false then curVal = 0 else curVal = tonumber(curVal) end; curVal = curVal tonumber(ARGV[1]); redis.call("set", KEYS[1], curVal); return curVal' "be4f93d8a5379e5e5b768a74e77c8a4eb0434441" 调用: 127.0.0.1:6379> set num 2OK127.0.0.1:6379> evalsha be4f93d8a5379e5e5b768a74e77c8a4eb0434441 1 num 6 (integer) 12 3.2.6 脚本超时 Redis 的指令执行本身是单线程的，这个线程还要执行客户端的 Lua 脚本，如果 Lua 脚本执行超时或者陷入了死循环，是不是没有办法为客户端提供服务了呢? eval 'while(true) do end' 0 为了防止某个脚本执行时间过长导致 Redis 无法提供服务，Redis 提供了 lua-time-limit 参数限制脚本的最长运行时间，默认为 5 秒钟。 lua-time-limit 5000(redis.conf 配置文件中) 当脚本运行时间超过这一限制后，Redis 将开始接受其他命令但不会执行(以确保脚本的原子性，因为此时脚本并没有被终止)，而是会返回“BUSY”错误。 Redis 提供了一个 script kill 的命令来中止脚本的执行。新开一个客户端: script kill 如果当前执行的 Lua 脚本对 Redis 的数据进行了修改(SET、DEL 等)，那么通过 script kill 命令是不能终止脚本运行的。 127.0.0.1:6379> eval "redis.call('set','gupao','666') while true do end" 0 因为要保证脚本运行的原子性，如果脚本执行了一部分终止，那就违背了脚本原子性的要求。最终要保证脚本要么都执行，要么都不执行。 127.0.0.1:6379> script kill(error) UNKILLABLE Sorry the script already executed write commands against the dataset. You can either wait the scripttermination or kill the server in a hard way using the SHUTDOWN NOSAVE command. 遇到这种情况，只能通过 shutdown nosave 命令来强行终止 redis。 shutdown nosave 和 shutdown 的区别在于 shutdown nosave 不会进行持久化操作，意味着发生在上一次快照后的数据库修改都会丢失。 4、Redis 为什么这么快? 4.1 Redis到底有多快？ 根据官方的数据，Redis 的 QPS 可以达到 10 万左右(每秒请求数)。 4.2 Redis为什么这么快? 总结:1)纯内存结构、2)单线程、3)多路复用 4.2.1 内存 KV 结构的内存数据库，时间复杂度 O(1)。 第二个，要实现这么高的并发性能，是不是要创建非常多的线程? 恰恰相反，Redis 是单线程的。 4.2.2 单线程 单线程有什么好处呢? 1、没有创建线程、销毁线程带来的消耗 2、避免了上线文切换导致的 CPU 消耗 3、避免了线程之间带来的竞争问题，例如加锁释放锁死锁等等 4.2.3 异步非阻塞 异步非阻塞 I/O，多路复用处理并发连接。 4.3 Redis为什么是单线程的? 不是白白浪费了 CPU 的资源吗? 因为单线程已经够用了，CPU 不是 redis 的瓶颈。Redis 的瓶颈最有可能是机器内存或者网络带宽。既然单线程容易实现，而且 CPU 不会成为瓶颈，那就顺理成章地采用单线程的方案了。 4.4 单线程为什么这么快? 因为 Redis 是基于内存的操作，我们先从内存开始说起。 4.4.1 虚拟存储器(虚拟内存 Vitual Memory) 名词解释:主存:内存;辅存:磁盘(硬盘) 计算机主存(内存)可看作一个由 M 个连续的字节大小的单元组成的数组，每个字节有一个唯一的地址，这个地址叫做物理地址(PA)。早期的计算机中，如果 CPU 需要内存，使用物理寻址，直接访问主存储器。 这种方式有几个弊端: 1、在多用户多任务操作系统中，所有的进程共享主存，如果每个进程都独占一块物理地址空间，主存很快就会被用完。我们希望在不同的时刻，不同的进程可以共用同一块物理地址空间。 2、如果所有进程都是直接访问物理内存，那么一个进程就可以修改其他进程的内存数据，导致物理地址空间被破坏，程序运行就会出现异常。 为了解决这些问题，我们就想了一个办法，在 CPU 和主存之间增加一个中间层。CPU 不再使用物理地址访问，而是访问一个虚拟地址，由这个中间层把地址转换成物理地址，最终获得数据。这个中间层就叫做虚拟存储器(Virtual Memory)。 具体的操作如下所示: 在每一个进程开始创建的时候，都会分配一段虚拟地址，然后通过虚拟地址和物理地址的映射来获取真实数据，这样进程就不会直接接触到物理地址，甚至不知道自己调用的哪块物理地址的数据。 目前，大多数操作系统都使用了虚拟内存，如 Windows 系统的虚拟内存、Linux 系统的交换空间等等。Windows 的虚拟内存(pagefile.sys)是磁盘空间的一部分。 在 32 位的系统上，虚拟地址空间大小是 2^32bit=4G。在 64 位系统上，最大虚拟地址空间大小是多少? 是不是 2^64bit=10241014TB=1024PB=16EB?实际上没有用到 64 位，因为用不到这么大的空间，而且会造成很大的系统开销。Linux 一般用低 48 位来表示虚拟地址空间，也就是 2^48bit=256T。 cat /proc/cpuinfo address sizes : 40 bits physical, 48 bits virtual 实际的物理内存可能远远小于虚拟内存的大小。 总结：引入虚拟内存，可以提供更大的地址空间，并且地址空间是连续的，使得程序编写、链接更加简单。并且可以对物理内存进行隔离，不同的进程操作互不影响。还可以通过把同一块物理内存映射到不同的虚拟地址空间实现内存共享。 4.4.2 用户空间和内核空间 为了避免用户进程直接操作内核，保证内核安全，操作系统将虚拟内存划分为两部分，一部分是内核空间(Kernel-space)/ˈkɜːnl /，一部分是用户空间(User-space)。 内核是操作系统的核心，独立于普通的应用程序，可以访问受保护的内存空间，也有访问底层硬件设备的权限。 内核空间中存放的是内核代码和数据，而进程的用户空间中存放的是用户程序的代码和数据。不管是内核空间还是用户空间，它们都处于虚拟空间中，都是对物理地址的映射。 在 Linux 系统中, 内核进程和用户进程所占的虚拟内存比例是 1:3。 当进程运行在内核空间时就处于内核态，而进程运行在用户空间时则处于用户态。 进程在内核空间以执行任意命令，调用系统的一切资源;在用户空间只能执行简单的运算，不能直接调用系统资源，必须通过系统接口(又称 system call)，才能向内核发出指令。 top 命令: us 代表 CPU 消耗在 User space 的时间百分比; sy 代表 CPU 消耗在 Kernel space 的时间百分比。 4.4.3 进程切换(上下文切换) 多任务操作系统是怎么实现运行远大于 CPU 数量的任务个数的? 当然，这些任务实际上并不是真的在同时运行，而是因为系统通过时间片分片算法，在很短的时间内，将 CPU 轮流分配给它们，造成多任务同时运行的错觉。 为了控制进程的执行，内核必须有能力挂起正在 CPU 上运行的进程，并恢复以前挂起的某个进程的执行。这种行为被称为进程切换。 什么叫上下文? 在每个任务运行前，CPU 都需要知道任务从哪里加载、又从哪里开始运行，也就是说，需要系统事先帮它设置好 CPU 寄存器和程序计数器(ProgramCounter)，这个叫做 CPU 的上下文。 而这些保存下来的上下文，会存储在系统内核中，并在任务重新调度执行时再次加载进来。这样就能保证任务原来的状态不受影响，让任务看起来还是连续运行。 在切换上下文的时候，需要完成一系列的工作，这是一个很消耗资源的操作。 4.4.4 进程的阻塞 正在运行的进程由于提出系统服务请求(如 I/O 操作)，但因为某种原因未得到操作系统的立即响应，该进程只能把自己变成阻塞状态，等待相应的事件出现后才被唤醒。 进程在阻塞状态不占用 CPU 资源。 4.4.5 文件描述符 FD Linux 系统将所有设备都当作文件来处理，而 Linux 用文件描述符来标识每个文件对象。 文件描述符(File Descriptor)是内核为了高效管理已被打开的文件所创建的索引，用于指向被打开的文件，所有执行 I/O 操作的系统调用都通过文件描述符;文件描述符是一个简单的非负整数，用以表明每个被进程打开的文件。 Linux 系统里面有三个标准文件描述符。 0:标准输入(键盘); 1:标准输出(显示器); 2:标准错误输出(显示器)。 4.4.6 传统 I/O 数据拷贝 以读操作为例: 当应用程序执行 read 系统调用读取文件描述符(FD)的时候，如果这块数据已经存在于用户进程的页内存中，就直接从内存中读取数据。如果数据不存在，则先将数据从磁盘加载数据到内核缓冲区中，再从内核缓冲区拷贝到用户进程的页内存中。(两次拷贝，两次 user 和 kernel 的上下文切换)。 I/O 的阻塞到底阻塞在哪里? 4.4.7 Blocking I/O 当使用 read 或 write 对某个文件描述符进行过读写时，如果当前 FD 不可读，系统就不会对其他的操作做出响应。从设备复制数据到内核缓冲区是阻塞的，从内核缓冲区拷贝到用户空间，也是阻塞的，直到 copy complete，内核返回结果，用户进程才解除 block 的状态。 为了解决阻塞的问题，我们有几个思路。 1、在服务端创建多个线程或者使用线程池，但是在高并发的情况下需要的线程会很多，系统无法承受，而且创建和释放线程都需要消耗资源。 2、由请求方定期轮询，在数据准备完毕后再从内核缓存缓冲区复制数据到用户空间 (非阻塞式 I/O)，这种方式会存在一定的延迟。 能不能用一个线程处理多个客户端请求? 4.4.8 I/O 多路复用(I/O Multiplexing) I/O 指的是网络 I/O。 多路指的是多个 TCP 连接(Socket 或 Channel)。 复用指的是复用一个或多个线程。它的基本原理就是不再由应用程序自己监视连接，而是由内核替应用程序监视文件描述符。 客户端在操作的时候，会产生具有不同事件类型的 socket。在服务端，I/O 多路复用程序(I/O Multiplexing Module)会把消息放入队列中，然后通过文件事件分派器(File event Dispatcher)，转发到不同的事件处理器中。 多路复用有很多的实现，以 select 为例，当用户进程调用了多路复用器，进程会被阻塞。内核会监视多路复用器负责的所有 socket，当任何一个 socket 的数据准备好了，多路复用器就会返回。这时候用户进程再调用 read 操作，把数据从内核缓冲区拷贝到用户空间。 所以，I/O 多路复用的特点是通过一种机制一个进程能同时等待多个文件描述符，而这些文件描述符(套接字描述符)其中的任意一个进入读就绪(readable)状态，select() 函数就可以返回。 Redis 的多路复用， 提供了 select, epoll, evport, kqueue 几种选择，在编译的时 候来选择一种。 evport 是 Solaris 系统内核提供支持的; epoll 是 LINUX 系统内核提供支持的; kqueue 是 Mac 系统提供支持的; select 是 POSIX 提供的，一般的操作系统都有支撑(保底方案); 源码 ae_epoll.c、ae_select.c、ae_kqueue.c、ae_evport.c 5、内存回收 Reids 所有的数据都是存储在内存中的，在某些情况下需要对占用的内存空间进行回 收。内存回收主要分为两类，一类是 key 过期，一类是内存使用达到上限(max_memory) 触发内存淘汰。 5.1 过期策略 要实现 key 过期，我们有几种思路。 5.1.1 定时过期(主动淘汰) 每个设置过期时间的 key 都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好;但是会占用大量的 CPU 资源去处理过期的 数据，从而影响缓存的响应时间和吞吐量。 5.1.2 惰性过期(被动淘汰) 只有当访问一个 key 时，才会判断该 key 是否已过期，过期则清除。该策略可以最大化地节省 CPU 资源，却对内存非常不友好。极端情况可能出现大量的过期 key 没有再次被访问，从而不会被清除，占用大量内存。 例如 String，在 getCommand 里面会调用 expireIfNeeded server.c expireIfNeeded(redisDb db, robj key) 第二种情况，每次写入 key 时，发现内存不够，调用 activeExpireCycle 释放一部分内存。 expire.c activeExpireCycle(int type) 5.1.3 定期过期 源码:server.h typedef struct redisDb { dict dict; / 所有的键值对 /dict expires; / 设置了过期时间的键值对 /dict blocking_keys; dict ready_keys; dict watched_keys; int id;long long avg_ttl;list defrag_later; } redisDb; 每隔一定的时间，会扫描一定数量的数据库的 expires 字典中一定数量的 key，并清除其中已过期的 key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得 CPU 和内存资源达到最优的平衡效果。 Redis 中同时使用了惰性过期和定期过期两种过期策略。 5.2 淘汰策略 Redis 的内存淘汰策略，是指当内存使用达到最大内存极限时，需要使用淘汰算法来决定清理掉哪些数据，以保证新数据的存入。 5.2.1 最大内存设置 redis.conf 参数配置: maxmemory <bytes> 如果不设置 maxmemory 或者设置为 0，64 位系统不限制内存，32 位系统最多使用 3GB 内存。 动态修改: redis> config set maxmemory 2GB 到达最大内存以后怎么办? 5.2.2 淘汰策略 https://redis.io/topics/lru-cache redis.conf maxmemory-policy noeviction 先从算法来看: LRU，Least Recently Used:最近最少使用。判断最近被使用的时间，目前最远的数据优先被淘汰。 LFU，Least Frequently Used，最不常用，4.0 版本新增。 random，随机删除。 如果没有符合前提条件的 key 被淘汰，那么 volatile-lru、volatile-random、 volatile-ttl 相当于 noeviction(不做内存回收)。 动态修改淘汰策略: redis> config set maxmemory-policy volatile-lru 建议使用 volatile-lru，在保证正常服务的情况下，优先删除最近最少使用的 key。 5.2.3 LRU 淘汰原理 问题：如果基于传统 LRU 算法实现 Redis LRU 会有什么问题? 需要额外的数据结构存储，消耗内存。 Redis LRU 对传统的 LRU 算法进行了改良，通过随机采样来调整算法的精度。如果淘汰策略是 LRU，则根据配置的采样值 maxmemory_samples(默认是 5 个), 随机从数据库中选择 m 个 key, 淘汰其中热度最低的 key 对应的缓存数据。所以采样参数m配置的数值越大, 就越能精确的查找到待淘汰的缓存数据,但是也消耗更多的CPU计算,执行效率降低。 问题：如何找出热度最低的数据? Redis 中所有对象结构都有一个 lru 字段, 且使用了 unsigned 的低 24 位，这个字段用来记录对象的热度。对象被创建时会记录 lru 值。在被访问的时候也会更新 lru 的值。 但是不是获取系统当前的时间戳，而是设置为全局变量 server.lruclock 的值。 源码：server.h typedef struct redisObject {unsigned type:4;unsigned encoding:4;unsigned lru:LRU_BITS;int refcount;void ptr; } robj; server.lruclock 的值怎么来的? Redis 中有个定时处理的函数 serverCron，默认每 100 毫秒调用函数 updateCachedTime 更新一次全局变量的 server.lruclock 的值，它记录的是当前 unix 时间戳。 源码:server.c void updateCachedTime(void) { time_t unixtime = time(NULL); atomicSet(server.unixtime,unixtime); server.mstime = mstime();​struct tm tm; localtime_r(&server.unixtime,&tm);server.daylight_active = tm.tm_isdst; } 问题:为什么不获取精确的时间而是放在全局变量中?不会有延迟的问题吗? 这样函数 lookupKey 中更新数据的 lru 热度值时,就不用每次调用系统函数 time，可以提高执行效率。 OK，当对象里面已经有了 LRU 字段的值，就可以评估对象的热度了。 函数 estimateObjectIdleTime 评估指定对象的 lru 热度，思想就是对象的 lru 值和全局的 server.lruclock 的差值越大(越久没有得到更新)，该对象热度越低。 源码 evict.c / Given an object returns the min number of milliseconds the object was never requested, using an approximated LRU algorithm. /unsigned long long estimateObjectIdleTime(robj o) {unsigned long long lruclock = LRU_CLOCK(); if (lruclock >= o->lru) {return (lruclock - o->lru) LRU_CLOCK_RESOLUTION; } else {return (lruclock + (LRU_CLOCK_MAX - o->lru)) LRU_CLOCK_RESOLUTION;} } server.lruclock 只有 24 位，按秒为单位来表示才能存储 194 天。当超过 24bit 能表 示的最大时间的时候，它会从头开始计算。 server.h define LRU_CLOCK_MAX ((1<<LRU_BITS)-1) / Max value of obj->lru / 在这种情况下，可能会出现对象的 lru 大于 server.lruclock 的情况，如果这种情况 出现那么就两个相加而不是相减来求最久的 key。 为什么不用常规的哈希表+双向链表的方式实现?需要额外的数据结构，消耗资源。而 Redis LRU 算法在 sample 为 10 的情况下，已经能接近传统 LRU 算法了。 问题:除了消耗资源之外，传统 LRU 还有什么问题? 如图，假设 A 在 10 秒内被访问了 5 次，而 B 在 10 秒内被访问了 3 次。因为 B 最后一次被访问的时间比 A 要晚，在同等的情况下，A 反而先被回收。 问题:要实现基于访问频率的淘汰机制，怎么做? 5.2.4 LFU server.h typedef struct redisObject {unsigned type:4;unsigned encoding:4;unsigned lru:LRU_BITS;int refcount;void ptr; } robj; 当这 24 bits 用作 LFU 时，其被分为两部分: 高 16 位用来记录访问时间(单位为分钟，ldt，last decrement time) 低 8 位用来记录访问频率，简称 counter(logc，logistic counter) counter 是用基于概率的对数计数器实现的，8 位可以表示百万次的访问频率。 对象被读写的时候，lfu 的值会被更新。 db.c——lookupKey void updateLFU(robj val) {unsigned long counter = LFUDecrAndReturn(val); counter = LFULogIncr(counter);val->lru = (LFUGetTimeInMinutes()<<8) | counter;} 增长的速率由，lfu-log-factor 越大，counter 增长的越慢 redis.conf 配置文件。 lfu-log-factor 10 如果计数器只会递增不会递减，也不能体现对象的热度。没有被访问的时候，计数器怎么递减呢? 减少的值由衰减因子 lfu-decay-time(分钟)来控制，如果值是 1 的话，N 分钟没有访问就要减少 N。 redis.conf 配置文件 lfu-decay-time 1 6、持久化机制 https://redis.io/topics/persistence Redis 速度快，很大一部分原因是因为它所有的数据都存储在内存中。如果断电或者宕机，都会导致内存中的数据丢失。为了实现重启后数据不丢失，Redis 提供了两种持久化的方案，一种是 RDB 快照(Redis DataBase)，一种是 AOF(Append Only File)。 6.1 RDB RDB 是 Redis 默认的持久化方案。当满足一定条件的时候，会把当前内存中的数据写入磁盘，生成一个快照文件 dump.rdb。Redis 重启会通过加载 dump.rdb 文件恢复数据。 什么时候写入 rdb 文件? 6.1.1 RDB 触发 1、自动触发 a)配置规则触发。 redis.conf， SNAPSHOTTING，其中定义了触发把数据保存到磁盘的触发频率。 如果不需要 RDB 方案，注释 save 或者配置成空字符串""。 save 900 1 900 秒内至少有一个 key 被修改(包括添加) save 300 10 400 秒内至少有 10 个 key 被修改save 60 10000 60 秒内至少有 10000 个 key 被修改 注意上面的配置是不冲突的，只要满足任意一个都会触发。 RDB 文件位置和目录: 文件路径，dir ./ 文件名称dbfilename dump.rdb 是否是LZF压缩rdb文件 rdbcompression yes 开启数据校验 rdbchecksum yes 问题：为什么停止 Redis 服务的时候没有 save，重启数据还在? RDB 还有两种触发方式: b)shutdown 触发，保证服务器正常关闭。 c)flushall，RDB 文件是空的，没什么意义(删掉 dump.rdb 演示一下)。 2、手动触发 如果我们需要重启服务或者迁移数据，这个时候就需要手动触 RDB 快照保存。Redis 提供了两条命令: a)save save 在生成快照的时候会阻塞当前 Redis 服务器， Redis 不能处理其他命令。如果内存中的数据比较多，会造成 Redis 长时间的阻塞。生产环境不建议使用这个命令。 为了解决这个问题，Redis 提供了第二种方式。 执行 bgsave 时，Redis 会在后台异步进行快照操作，快照同时还可以响应客户端请求。 具体操作是 Redis 进程执行 fork 操作创建子进程(copy-on-write)，RDB 持久化过程由子进程负责，完成后自动结束。它不会记录 fork 之后后续的命令。阻塞只发生在 fork 阶段，一般时间很短。 用 lastsave 命令可以查看最近一次成功生成快照的时间。 6.1.2 RDB 数据的恢复(演示) 1、shutdown 持久化添加键值 添加键值 redis> set k1 1 redis> set k2 2 redis> set k3 3 redis> set k4 4 redis> set k5 5 停服务器，触发 save redis> shutdown 备份 dump.rdb 文件 cp dump.rdb dump.rdb.bak 启动服务器 /usr/local/soft/redis-5.0.5/src/redis-server /usr/local/soft/redis-5.0.5/redis.conf 啥都没有: redis> keys 3、通过备份文件恢复数据停服务器 redis> shutdown 重命名备份文件 mv dump.rdb.bak dump.rdb 启动服务器 /usr/local/soft/redis-5.0.5/src/redis-server /usr/local/soft/redis-5.0.5/redis.conf 查看数据 redis> keys 6.1.3 RDB 文件的优势和劣势 一、优势 1.RDB 是一个非常紧凑(compact)的文件，它保存了 redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。 2.生成 RDB 文件的时候，redis 主进程会 fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘 IO 操作。 3.RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。 二、劣势 1、RDB 方式数据没办法做到实时持久化/秒级持久化。因为 bgsave 每次运行都要执行 fork 操作创建子进程，频繁执行成本过高。 2、在一定间隔时间做一次备份，所以如果 redis 意外 down 掉的话，就会丢失最后一次快照之后的所有修改(数据有丢失)。 如果数据相对来说比较重要，希望将损失降到最小，则可以使用 AOF 方式进行持久化。 6.2 AOF Append Only File AOF:Redis 默认不开启。AOF 采用日志的形式来记录每个写操作，并追加到文件中。开启后，执行更改 Redis 数据的命令时，就会把命令写入到 AOF 文件中。 Redis 重启时会根据日志文件的内容把写指令从前到后执行一次以完成数据的恢复工作。 6.2.1 AOF 配置 配置文件 redis.conf 开关appendonly no 文件名appendfilename "appendonly.aof" AOF 文件的内容(vim 查看): 问题：数据都是实时持久化到磁盘吗? 由于操作系统的缓存机制，AOF 数据并没有真正地写入硬盘，而是进入了系统的硬盘缓存。什么时候把缓冲区的内容写入到 AOF 文件? 问题:文件越来越大，怎么办? 由于 AOF 持久化是 Redis 不断将写命令记录到 AOF 文件中，随着 Redis 不断的进行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。 例如 set xxx 666，执行 1000 次，结果都是 xxx=666。 为了解决这个问题，Redis 新增了重写机制，当 AOF 文件的大小超过所设定的阈值时，Redis 就会启动 AOF 文件的内容压缩，只保留可以恢复数据的最小指令集。 可以使用命令 bgrewriteaof 来重写。 AOF 文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的 AOF 文件。 重写触发机制 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb 问题:重写过程中，AOF 文件被更改了怎么办? 另外有两个与 AOF 相关的参数: 6.2.2 AOF 数据恢复 重启 Redis 之后就会进行 AOF 文件的恢复。 6.2.3 AOF 优势与劣势 优点: 1、AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis 最多也就丢失 1 秒的数据而已。 缺点: 1、对于具有相同数据的的 Redis，AOF 文件通常会比 RDB 文件体积更大(RDB 存的是数据快照)。 2、虽然 AOF 提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。在高并发的情况下，RDB 比 AOF 具好更好的性能保证。 6.3 两种方案比较 那么对于 AOF 和 RDB 两种持久化方式，我们应该如何选择呢? 如果可以忍受一小段时间内数据的丢失，毫无疑问使用 RDB 是最好的，定时生成 RDB 快照(snapshot)非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。 否则就使用 AOF 重写。但是一般情况下建议不要单独使用某一种持久化机制，而是应该两种一起用，在这种情况下,当 redis 重启的时候会优先载入 AOF 文件来恢复原始的数据，因为在通常情况下 AOF 文件保存的数据集要比 RDB 文件保存的数据集要完整。 本篇文章为转载内容。原文链接：https://blog.csdn.net/zhoutaochun/article/details/120075092。 该文由互联网用户投稿提供，文中观点代表作者本人意见，并不代表本站的立场。 作为信息平台，本站仅提供文章转载服务，并不拥有其所有权，也不对文章内容的真实性、准确性和合法性承担责任。 如发现本文存在侵权、违法、违规或事实不符的情况，请及时联系我们，我们将第一时间进行核实并删除相应内容。

...原生技术的快速发展，Kafka作为分布式消息中间件的应用场景愈发广泛。特别是在微服务架构日益普及的背景下，Kafka因其高吞吐量、低延迟的特点，成为了企业级数据流处理的首选方案。然而，这也带来了新的挑战。例如，国内某大型电商企业在双十一促销活动中，由于订单峰值激增，其基于Kafka构建的实时交易系统一度面临消息堆积的问题。经过紧急排查，发现主要是由于分区数量不足导致的负载不均。为此，该企业迅速调整了分区策略，并优化了消息生产和消费逻辑，最终顺利应对了高峰流量。 与此同时，国外科技巨头也对Kafka进行了持续改进。近日，Confluent公司宣布推出Kafka 3.6版本，该版本引入了多项新特性，包括增强型事务API、更高效的压缩算法以及对多租户环境的支持。这些更新旨在帮助企业更好地满足复杂业务场景的需求，同时也反映了Kafka社区对于技术创新的不懈追求。 此外，关于Kafka与ZooKeeper的关系，业界普遍关注其未来的演进方向。尽管Confluent正在推动KRaft（Kafka Raft-based Controller）项目，试图完全摆脱ZooKeeper的依赖，但在短期内，ZooKeeper仍将在许多传统部署环境中占据主导地位。因此，对于正在使用Kafka的企业而言，如何平衡现有基础设施与新技术之间的过渡，成为了一个值得深思的问题。 从长远来看，Kafka的成功离不开开源社区的支持。正如Apache软件基金会所倡导的理念，“开放、协作、共享”始终是推动技术创新的核心动力。在未来，随着更多企业和开发者加入到Kafka生态中，我们有理由相信，这一技术将继续保持旺盛的生命力，并在更多领域发挥重要作用。

...ne 的调度器进行了优化，进一步提升了并发效率，这对于Beego等框架下的异步任务处理带来了更为强大的性能支持。同时，RabbitMQ社区也不断推出新特性及优化方案，比如改进了其延迟队列功能，使得开发者能更精准地控制任务执行的延时时间，增强了应用场景的多样性和灵活性。 此外，近年来随着Kafka、NATS等消息中间件的流行，它们也被广泛应用于异步任务处理中，并且有越来越多的开源库如go-rabbitmq、go-kafka-client等为Go语言提供了便捷的接口来集成这些队列系统，为Beego框架下构建高性能分布式系统提供了更多选择。 对于深入理解异步任务处理机制的开发者而言，可以参考《C.A.R. Hoare的 CSP 理论与 Go 语言并发模型实践》一文，该文通过理论结合实践的方式，剖析了Go语言goroutine背后的设计理念以及如何在实际项目如Beego框架中更好地运用这一强大工具。 综上所述，在当今技术发展背景下，理解和掌握异步任务处理和队列系统的应用不仅有利于提高Beego框架项目的开发效能，也能紧跟行业趋势，应对复杂业务场景的挑战。

...两种时间概念，在应对延迟数据和实时数据的问题上，各有各的独特用法和特点，可以说是各显神通呢！这篇东西呢，咱们会仔仔细细地掰扯这两种时间概念的处理手法，还会一起聊聊它们在实际生活中怎么用、有哪些应用场景，保准让你看得明明白白！ 二、 Processing Time 的处理方式及应用场景 Processing Time 是 Spark Structured Streaming 中的一种时间概念，它的基础是应用程序的时间，而不是系统的时间。也就是说， Processing Time 代表了程序从开始运行到处理数据所花费的时间。 在处理实时数据时， Processing Time 可能是一个很好的选择，因为它可以让您立即看到新的数据并进行相应的操作。比如，假如你现在正在关注你网站的访问情况，这个Processing Time功能就能马上告诉你，现在到底有多少人在逛你的网站。 以下是使用 Processing Time 处理实时数据的一个简单示例： java val dataStream = spark.readStream.format("socket").option("host", "localhost").option("port", 9999).load() .selectExpr("CAST(text AS STRING)") .withWatermark("text", "1 second") .as[(String, Long)] val query = dataStream.writeStream .format("console") .outputMode("complete") .start() query.awaitTermination() 在这个示例中，我们创建了一个 socket 数据源，然后将其转换为字符串类型，并设置 watermark 为 1 秒。这就意味着，如果我们收到的数据上面的时间戳已经超过1秒了，那这个数据就会被我们当作是迟到了的小淘气，然后选择性地忽略掉它。 三、 Event Time 的处理方式及应用场景 Event Time 是 Spark Structured Streaming 中的另一种时间概念，它是根据事件的实际发生时间来确定的。这就意味着，就算大家在同一秒咔嚓一下按下发送键，由于网络这个大迷宫里可能会有延迟、堵车等各种状况，不同信息到达目的地的顺序可能会乱套，处理起来自然也就可能前后颠倒了。 在处理延迟数据时， Event Time 可能是一个更好的选择，因为它可以根据事件的实际发生时间来确定数据的处理顺序，从而避免丢失数据。比如，你正在处理电子邮件的时候，Event Time这个功能就相当于你的超级小助手，它能确保你按照邮件发送的时间顺序，逐一、有序地处理这些邮件，就像排队一样井然有序。 以下是使用 Event Time 处理延迟数据的一个简单示例： python from pyspark.sql import SparkSession spark = SparkSession.builder.appName("Structured Streaming").getOrCreate() data_stream = spark \ .readStream \ .format("kafka") \ .option("kafka.bootstrap.servers", "localhost:9092") \ .option("subscribe", "my-topic") \ .load() \ .selectExpr("CAST(key AS STRING)", "CAST(value AS STRING)") query = data_stream \ .writeStream \ .format("console") \ .outputMode("append") \ .start() query.awaitTermination() 在这个示例中，我们从 kafka 主题读取数据，并设置 watermark 为 1 分钟。这就意味着，如果我们超过一分钟没收到任何新消息，那我们就会觉得这个topic已经没啥动静了，到那时咱就可以结束查询啦。 四、 结论 在 Spark Structured Streaming 中， Processing Time 和 Event Time 是两种不同的时间概念，它们分别适用于处理实时数据和处理延迟数据。理解这两种时间概念以及如何在实际场景中使用它们是非常重要的。希望这篇文章能够帮助你更好地理解和使用 Spark Structured Streaming。

...该插件致力于在图片从服务器加载至浏览器的过程中，为用户提供视觉上的加载进度反馈，以增加交互性和用户感知度。其核心功能在于，当图片资源请求时，会在原图片位置显示一个垂直渐进式的加载动画效果，使得页面元素的加载过程更为生动且具有吸引力。使用这款插件可以有效避免因图片加载延迟导致的页面布局抖动问题，同时也提升了用户体验，让用户在等待图片完全加载的同时能够明确感知到加载进程正在进行中。插件实现方式简洁易用，只需简单的配置和调用即可将原本静态的图片加载过程转变为炫酷的动画展示，是现代Web开发中优化加载性能、美化页面过渡效果的理想工具之一。 点我下载 文件大小：196.59 KB 您将下载一个JQuery插件资源包，该资源包内部文件的目录结构如下： 本网站提供JQuery插件下载功能，旨在帮助广大用户在工作学习中提升效率、节约时间。 本网站的下载内容来自于互联网。如您发现任何侵犯您权益的内容，请立即告知我们，我们将迅速响应并删除相关内容。 免责声明：站内所有资源仅供个人学习研究及参考之用，严禁将这些资源应用于商业场景。 若擅自商用导致的一切后果，由使用者承担责任。

...oaded还能够帮助优化网站性能。通过实时监控图片加载情况，它可以延迟一些非关键图片的加载时间，直到其所在部分进入视窗范围，这不仅加快了页面首次加载速度，也减少了不必要的服务器请求，进一步提升了网站的整体性能。总而言之，imagesLoaded是一个非常实用且易于集成到现有项目的工具，无论是为了改善用户体验，还是为了实现更复杂的动态内容加载效果，它都是你的理想选择。通过利用imagesLoaded，你可以确保每个访客都能享受到流畅、美观且功能完善的网页浏览体验。 点我下载 文件大小：37.97 KB 您将下载一个JQuery插件资源包，该资源包内部文件的目录结构如下： 本网站提供JQuery插件下载功能，旨在帮助广大用户在工作学习中提升效率、节约时间。 本网站的下载内容来自于互联网。如您发现任何侵犯您权益的内容，请立即告知我们，我们将迅速响应并删除相关内容。 免责声明：站内所有资源仅供个人学习研究及参考之用，严禁将这些资源应用于商业场景。 若擅自商用导致的一切后果，由使用者承担责任。

...a 17也提供了新的优化，如对线程池大小动态调整的支持，有助于在保证系统性能的同时避免资源浪费。而Java社区对于并行计算和GPU加速的探索也在不断深入，例如Project Loom计划中的ZGC垃圾收集器，旨在提供更好的线程安全性与性能。 同时，随着微服务架构的流行，Java并发编程的挑战也转向了如何设计和管理复杂的分布式系统。研究者们正在探索如何在分布式环境中实现高效的线程通信，如零拷贝、低延迟网络编程等。 总的来说，Java多线程技术的发展不仅体现在语言层面的更新，更在于如何帮助开发者解决实际问题，提高系统的并发性能和可扩展性。无论是企业级应用开发还是新兴技术领域，Java的并发编程能力都将发挥关键作用。

...态设置的系统变量，并优化了全局变量与会话变量的处理机制，使得管理员可以根据实时负载更加灵活地调整数据库配置。 同时，针对特定场景下的系统变量调优策略也值得研究。例如，在高并发访问环境中，合理设置“innodb_buffer_pool_size”、“innodb_log_file_size”等与内存管理和事务日志相关的系统变量，可以显著提升数据库性能并降低延迟。此外，“max_connections”的设置也需要结合服务器硬件资源以及实际并发连接需求进行科学规划。 值得注意的是，随着云原生数据库服务的发展，许多云服务商提供了对MySQL系统变量自动调节的服务，如AWS RDS的参数组功能，能够根据实例类型、工作负载模式智能调整系统变量，减轻运维负担的同时确保数据库运行效率。 综上所述，不仅需要熟练掌握MySQL系统变量的查看与设置方法，更要紧跟技术发展趋势，结合实际情况及数据库最佳实践进行深度调优，以实现数据库系统的高效稳定运行。

...格式，设计用于在现代网络浏览器中运行高性能客户端和服务器应用。文中虽然未直接提及WebAssembly，但作为一种前沿技术趋势，它可以使得像“我的世界”这样的大型游戏直接在浏览器中运行，无需下载安装，增强了网页游戏的便捷性和可访问性。 WebGL , Web图形库（Web Graphics Library），是一种JavaScript API，允许开发者在任何兼容的Web浏览器中无需插件就能渲染高质量的3D图形和2D图形。结合文章语境，在当前Web技术的发展背景下，WebGL的优化升级显著提升了网页游戏的画面渲染效果和性能表现，使得网页游戏能够达到与原生应用相近甚至相同的视觉体验，如《Astroneer》的成功案例所示。 CSS3 , 层叠样式表版本3（Cascading Style Sheets Level 3），是对CSS规范的最新修订版，提供了一系列增强网页布局、颜色、字体和其他设计元素的新特性。在制作“我的世界”游戏页面时，CSS3可以用来实现Logo动态展示、游戏界面丰富化和交互性的提升，进一步优化用户体验，例如通过动画效果吸引用户注意或通过自定义样式展现独特的游戏主题风格。

...库备份与恢复策略以及服务器运行状态监控，是确保数据库稳定高效运行的关键。 近期，一篇由MySQL官方博客发布的《深入理解MySQL权限系统》文章详尽解读了如何精确配置用户权限以避免因权限不足导致的访问错误。文中强调了GRANT和REVOKE命令在分配、撤销特定数据库或表访问权限时的重要性，并提醒用户注意MySQL中大小写敏感设置对表名的影响。 与此同时，关于数据库运维实践，《数据库灾难恢复：从理论到实战》一文结合实例探讨了当数据库表被误删后，如何通过定期备份快速进行数据恢复，并介绍了MySQL自带的binlog日志工具在实时数据同步及增量恢复中的应用。 此外，针对MySQL连接故障问题，InfoQ的一篇报道《优化MySQL连接池配置，提升数据库性能》指出，除了确认服务器运行状态和登录凭据外，合理配置数据库连接池参数也是防止连接故障的有效手段。文章提醒开发者关注连接超时设定、最大连接数限制等关键配置项，以应对高并发场景下的数据库连接挑战。 总之，在实际操作MySQL数据库过程中，不断学习并掌握最新最佳实践，对于解决“Table 'database_name.table_name' doesn't exist”这类常见错误，乃至提高整体数据库管理水平具有深远意义。

...期，一项关于前端性能优化的研究报告指出，超过30%的加载和渲染延迟问题源于HTML标签错误或不规范的资源引用。例如，未闭合的标签可能导致浏览器解析DOM树时产生误解，影响CSS选择器匹配与JavaScript执行，进而引发页面布局错乱甚至空白的问题。 实际上，随着Web Components、Shadow DOM等现代Web技术的发展，遵循语义化标准编写HTML的重要性更加凸显。Google在其AMP（Accelerated Mobile Pages）项目中就强调了正确使用HTML标签以提升页面性能的重要性，明确要求开发者注意标签闭合、属性完整等编码规范。 此外，在实际项目中，如电商平台或新闻网站，由于图片资源众多，确保标签的src属性设置准确无误尤为关键。近期有报道显示，某知名电商网站因部分商品图片路径失效导致用户体验下降，经过排查发现是由于后台生成的HTML代码中图片src属性值未能动态更新所造成。这一实例再次提醒我们，即便是在动态生成内容的场景下，也要严格把控HTML代码质量，避免出现类似资源加载失败的现象。 总结来说，无论从基础的网页开发规范还是前沿的性能优化实践来看，深入理解和重视HTML代码编写中的细微之处，对于构建高质量、高性能的Web应用都具有重要意义。在日常开发工作中，定期进行代码审查，借助自动化工具检查标签闭合、资源引用等问题，将有助于减少因这类低级错误带来的用户界面故障，并有效提升整体项目的稳定性和用户体验。

...用于直接与MySQL服务器交互的文本界面工具。用户可以通过输入SQL语句来执行各种数据库操作，如创建数据库、表，插入、修改和删除数据，以及查询数据库版本等。在本文上下文中，开发者或管理员使用MySQL命令行客户端输入特定的SQL命令“SELECT VERSION();”来查询MySQL服务器的当前版本号。 Web应用程序 , Web应用程序是一种运行于网络服务器上并通过HTTP协议与用户的Web浏览器进行交互的应用程序。用户通过浏览器访问Web应用程序，可以查看、提交信息或者进行其他复杂的数据处理任务。在开发Web应用程序时，MySQL作为后台数据库系统被广泛采用，用于存储和管理应用程序需要处理的各种数据。例如，电子商务网站可能利用MySQL来存储商品信息、订单记录、用户账户等数据，确保了数据的安全存储和高效检索。

...显。例如，近期各大云服务商如AWS、Azure等推出了一系列优化JSON数据传输性能的服务和工具，允许开发者以更低延迟、更高效率的方式处理JSON数据。 此外，针对JSON的安全性问题，Mozilla基金会发布了一项关于JSON安全漏洞的研究报告，提醒开发者注意防范由于不恰当的数据验证导致的XSS攻击，强调在解析JSON时进行严格的数据类型检查与过滤。同时，ECMAScript（ES）规范也在不断演进，例如ES2019引入了JSON.stringify()方法的可选参数replacer，它能提供更为精细的控制，使得开发者能够选择性地序列化JSON对象中的特定属性。 另外，在前端框架React、Vue.js中，JSON数据的处理也得到了深度集成，通过状态管理库如Redux、Vuex，开发者可以便捷地操作JSON数据并在组件间传递。这些框架通常会提供工具函数或API，简化对JSON数据的遍历、更新和响应式绑定。 综上所述，掌握JavaScript中遍历JSON数据的基本技巧仅仅是开始，了解JSON在现代Web开发中的前沿应用、安全风险以及相关技术的发展趋势，对于提升项目质量和开发效率具有重要意义。

...期，一项关于前端性能优化的研究指出，使用JSON进行数据交换和存储的方式，在移动优先、响应式设计以及SPA（单页应用）等主流开发模式中，能够显著降低网络传输负担，提升用户体验。 具体来说，各大云服务提供商如AWS、Azure和Google Cloud也纷纷推出对JSON格式原生支持的服务，如AWS DynamoDB可以直接处理JSON文档，大大简化了数据读写操作的复杂性。同时，Node.js社区不断涌现新的库和工具，以提高JSON数据处理效率，例如fast-json-stringify和json-bigint等，它们针对大数据量场景进行了深度优化，使得JSON在企业级应用中也能游刃有余。 此外，考虑到安全性问题，业界也在探索如何在保证JSON便捷性的前提下增强其安全性。例如，通过JSON Schema实现数据验证，确保接收到的数据符合预期结构，减少因数据格式错误引发的安全隐患。而在加密方面，已有研究提出了将JSON与加密算法结合，构建安全的数据交换通道。 综上所述，JSON作为跨平台、易于解析且高效的数据格式，在当前及未来一段时间内将持续发挥关键作用。无论是前端交互、后端数据处理，还是云端存储，深入理解和掌握JSON的应用与最佳实践，都将有助于开发者应对日新月异的技术挑战，打造更高效、更安全的数字化产品。

在处理与Zabbix服务器及SELinux相关的权限问题时，除了临时关闭或永久禁用SELinux外，更安全且推荐的做法是调整SELinux策略以适应Zabbix服务的运行需求。实际上，针对特定应用如Zabbix进行SELinux上下文和模块的定制化配置，可以在保持系统安全的同时确保服务正常运行。 近期（根据实际日期填写），Zabbix官方社区发布了一篇关于如何在启用SELinux环境下正确配置Zabbix的文章，详细阐述了如何编写自定义SELinux模块，为Zabbix服务创建适当的端口、文件和目录类型的标签，以及如何设置布尔值以允许Zabbix与必要的套接字进行交互。通过遵循这些指导步骤，用户可以在享受SELinux提供的强大安全保障的同时，避免因权限问题导致的服务启动失败。 此外，Linux内核开发者和安全专家也不断强调，不应轻易禁用SELinux，而是应深入了解并利用其规则来优化系统安全性。例如，在一篇由Red Hat发布的技术博客中，作者深入剖析了SELinux的工作原理，并给出了针对类似“Permission denied”错误的实战解决方案，其中包括如何查看和修改SELinux上下文，以及使用audit2allow工具生成自定义模块。 总之，面对Zabbix等应用程序与SELinux之间的兼容性问题，应当优先选择细化SELinux策略，而不是简单地禁用它。通过查阅最新的官方文档、社区讨论和技术博客，可以获取到实时有效的解决方案，帮助系统管理员更好地驾驭SELinux，确保系统的安全稳定运行。

...中，图片资源的管理和优化始终是开发者关注的重点。随着技术发展和最佳实践的不断演进，Webpack 5及以上版本对图片资源处理提供了更多高级特性，例如Tree Shaking、Asset Modules等，使得图片按需加载与压缩更为高效。近期，Vue CLI团队也针对静态资源路径配置进行了改进，允许开发者更灵活地自定义publicPath以适应多环境部署。 同时，随着前端工程化的日益成熟，越来越多的开发者开始探讨并实践使用CDN加速图片加载，通过将图片资源托管在CDN服务器上，不仅可以减轻源站压力，还能利用CDN的全球分发网络提高用户访问速度。Vue项目中可以结合vue-cli提供的环境变量功能，在不同环境下动态设置publicPath指向相应的CDN地址。 此外，对于现代Web应用而言，SVG图标因其矢量特性及可编程性而备受推崇，Vue项目中可通过引入诸如vue-svg-loader这样的第三方loader，实现SVG文件的按需导入与组件化管理，从而进一步提升性能和代码组织结构。 深入到具体业务场景，如PWA（Progressive Web App）的开发，Vue生态中也有成熟的解决方案，如Vue PWA插件，它不仅能帮助我们轻松实现离线缓存图片资源，还支持添加manifest文件以便让用户将网站添加至主屏幕，提供接近原生应用的用户体验。 综上所述，无论是基础的图片路径管理还是深度的性能优化策略，Vue.js都在持续为开发者提供强大且易用的工具链支持，以适应快速变化的前端开发需求。在实际项目中，理解并合理运用这些技术和方法，将有助于我们构建出体验更优、性能更强的Web应用。

...Script能够用于服务器端编程，从而实现全栈式JavaScript开发。同时，新兴的WebAssembly技术也为JavaScript性能优化提供了新的可能，允许开发者使用其他语言编写高性能模块并直接在浏览器中运行。 时至今日，JavaScript已经发展出了丰富多样的生态系统，包括React、Vue.js等现代前端框架，以及TypeScript这一JavaScript的超集，为大型项目提供静态类型检查和更严格的代码规范。此外，诸如GraphQL这样的数据查询与操作语言也与JavaScript紧密结合，革新了API设计与交互方式。 值得关注的是，浏览器厂商正积极支持并推动JavaScript标准——ECMAScript（ES）的迭代更新，如最新的ES2022版本引入了顶级await、类字段声明等新特性，进一步增强了JavaScript的表达能力和开发效率。 而在实际应用中，JavaScript在物联网(IoT)、移动应用（通过React Native、Ionic等框架）、游戏开发（Phaser、Three.js等库）等领域也展现出强大的适应性和扩展性。 综上所述，JavaScript不再仅是网页动态效果的工具，而是已成为一种通用型编程语言，在众多技术领域中发挥着举足轻重的作用。对于JavaScript开发者来说，关注并掌握这些最新趋势和技术动态，无疑将大大提升自身的职业竞争力，并更好地应对快速变化的技术挑战。

...的最新发展动态与部署优化策略。近期，MySQL 8.0版本发布了一系列重大更新，包括性能提升、安全增强以及对JSON文档处理能力的大幅改进。MySQL官方持续优化其在Linux环境下的运行效能，用户可通过查阅官方文档学习如何根据自身服务器硬件配置和业务需求调整MySQL的配置参数以实现最佳性能。 此外，对于企业级应用而言，MySQL的高可用性和扩展性至关重要。为确保服务稳定，很多企业采用主从复制、分片集群等高级部署架构，并借助于ProxySQL等中间件进行流量管理和负载均衡。同时，Percona Server for MySQL和MariaDB作为MySQL的两大分支，也在不断推出新功能并优化性能，为用户提供更多选择。 值得一提的是，随着容器化和云原生技术的发展，MySQL在Kubernetes集群中的部署实践也日益丰富。通过Operator模式或者Helm Chart等方式，可以更便捷地在云环境中部署和管理MySQL实例，实现自动化运维和弹性伸缩。 综上所述，掌握MySQL在Linux系统上的安装路径只是基础操作之一，深入了解MySQL的最新特性、部署策略及云环境下的运维实践，将有助于广大开发者和DBA更好地构建和维护高性能、高可用的数据库服务。

...适应这一趋势，各大云服务提供商如AWS、阿里云等都提供了托管版MySQL服务，用户可以便捷地部署和管理MySQL数据库，同时享受到自动备份、高可用性和弹性扩展等高级功能。例如，AWS RDS for MySQL不仅简化了数据库管理任务，还通过读副本、多可用区部署等功能确保了数据的安全与高可用性（来源：AWS官方文档，2023年）。 在实际应用层面，对于Web开发者而言，掌握如何优化MySQL插入语句以提升数据写入效率至关重要。一篇来自Stack Overflow的深度讨论中，专家们就如何避免全表锁定、利用批量插入提高性能等问题进行了详细解读，并分享了一些实战经验（来源：Stack Overflow，2023年）。通过学习这些最新的技术资讯和发展趋势，可以帮助开发者更好地应对实际开发中的挑战，最大化发挥MySQL数据库的优势，从而为构建高效稳定的应用程序提供强大支撑。

...数据库安全与远程访问优化至关重要。近日，随着云计算和分布式应用的普及，MySQL数据库远程管理的需求日益增加，但同时也带来了更严峻的安全挑战。据2022年的一份网络安全报告指出，针对数据库系统的未授权访问攻击事件增长了近30%，其中大量案例源于弱口令或不当的远程访问设置。 为强化MySQL远程连接安全性，建议关注以下几个方面： 1. 强化身份验证机制：采用双因素认证或多因素认证，避免仅依赖用户名和密码；启用MySQL的SSL加密连接功能，确保数据传输过程中的安全性。 2. 权限最小化原则：遵循“按需分配”的权限策略，只给每个用户提供完成其工作所需的最低权限，减少潜在的安全风险。 3. 定期审计与更新：定期审查MySQL用户表中的远程访问权限设置，及时移除不再需要的远程访问账号；同时保持MySQL服务器及其插件的版本更新，利用最新安全补丁修复已知漏洞。 4. 配合防火墙规则：在服务器层面，结合IPtables或其他防火墙工具精细控制对MySQL服务端口（默认3306）的访问，只允许特定可信IP地址进行远程连接。 5. 利用专门的数据库访问代理服务：对于大型企业或高安全需求场景，可考虑部署数据库访问代理服务，如Amazon RDS Proxy、Azure Database for MySQL Flexible Server等，它们提供了细粒度的访问控制、负载均衡及日志审计等功能，有助于提升远程访问MySQL数据库的整体安全性。 总之，在实现MySQL数据库远程访问便利性的同时，务必重视并实施严格的安全措施，以确保数据库资源不被恶意利用，有效保障企业信息资产的安全。