精华内容
下载资源
问答
  • 优化建议怎么写
    千次阅读
    2022-03-12 09:50:39

    1. 硬件和操作系统层面的优化

    从硬件层面来说,影响MySQL性能因素主要是CPU,可用内存大小,磁盘读写速度,网络带宽。从操作系统层面来说,应用文件句柄数,操作系统的网络配置,都会影响到MySQL的性能。主要观察服务本身所承载的体量,然后提出合理的指标要求,避免出现资源浪费的一个现象。

    2. 架构设计层面的优化

    MySQL是一个磁盘IO访问,非常频繁的关系型数据库,在高并发和高性能的场景中,MySQL数据库必然会承受巨大的并发压力,在此时我们的优化的方式,主要可以分为几个部分:

    (1) 第一个是搭建MySQL主从集群,单个MySQL服务容易去导致单点故障,一旦服务宕机,将会导致依赖MySQL数据库的应用,全部无法响应,主从集群或者主主集群,都可以去保证服务的高可用性。
    (2) 读写分离设计,在读多写少的场景中,通过读写分离的方案,可以去避免读写冲突,导致的性能问题。
    (3) 引入分库分表的机制,通过分库可以降低单个服务器一个IO压力。通过分表的方式,降低单表数据量,从而去提升sql的查询效率。
    (4) 针对热点数据,可以引入更为高效的分布式数据库,如Redis、MongoDB等,他们可以很好的减轻MySQL的访问压力,同时还能提升数据的检索性能

    3. MySQL程序配置优化

    MYSQL是一个经过互联网大厂检验过的生产级别的成熟数据库,对于MySQL数据库本身的优化,一般可以通过MySQL配置文件my.cnf来完成。
    第一个MySQL 5.7版本默认的最大连接数是151个,这个值可以再my.cnf中去修改。
    第二个binlog日志默认不开启,可以开启。
    第三个是缓存池Bufferpool默认大小配置,而这些配置一般是和用户的安装环境以及使用场景有关系,因此这些配置,官方只会提供一个默认的配置,具体的情况还需要使用者去根据实际情况去修改。
    关于配置项的修改,需要关注两个层面,第一个是配置的作用域,它可以分为会话级别和全局范围。第二个是是否支持热加载,针对这两个点,我们需要注意的是,全局参数的设定,对于已经存在的会话是无法生效的,会话参数的设定,随着会话的销毁而失效。第三个是全局类的统一配置,建议配置在默认配置文件中,否则重启服务会导致配置失效。

    4. SQL执行优化

    (1) 慢SQL的定位和排查,我们可以通过慢查询日志和慢查询日志工具分析,得到有问题的SQL列表。
    (2) 执行计划分析,针对慢SQL我们可以使用关键字explain来去查看当前sql的执行计划,可重点关注type,key,rows,filterd等字段,从而去定位该SQL执行慢的根本原因,再去有的放矢的进行优化。
    (3) 使用show profile工具,这个工具是MySQL提供的可以用来分析当前会话中SQL语句资源消耗情况的工具,可以用于SQL调优的测量,在当前会话中,默认情况下,show profile是关闭状态,打开以后会保存,最近15次的运行结果,针对运行慢的SQL通过profile工具进行详细分析,可以得到SQL执行过程中所有资源的开销情况,比如io开销,cpu开销,内存开销。

    sql优化规则

    1. SQL的查询一定要基于索引来进行数据扫描。
    2. 避免索引列上使用函数或者运算符。
    3. Where字句中like%号尽量放置在右边。
    4. 使用索引扫描,联合索引中的列从左往后,命中越多越好
    5. 尽可能使用SQL语句用到的索引完成排序
    6. 查询有效的列信息即可,少用*代替列信息
    7. 永远要用小的结果集驱动大的结果集
    更多相关内容
  • 1. 记住阿姆达尔定律:  Ahmdal's rule  funccost是函数func运行时间百分比,funcspeedup是你优化函数的...  这并不意味着用8周时间一个全功能的射线追踪算法,然后用8周时间去优化它。  分多步来做性能优化
  • 一般说来Web前端指网站业务逻辑之前的部分,包括浏览器加载、网站视图模型、图片服务、CDN服务等,主要优化手段有优化浏览器访问、使用反向代理、CDN加速等
  • 所以我们会如下的SQL语句: select top 100 * from 表 order by Score desc 如果表非常大的话,那么这样的操作是非常消耗资源的,因为SQL SERVER要对整个表进行排序,然后取前N条记录.这样的造作是在Temdb
  • 通过这种机制,我们可以构造一个读/写优化的索引,该索引能够提供比以前的闪存感知索引更好的总体性能。 此外,我们对提出的索引进行了分析,结果表明,仅通过调整Bloom过滤器的假阳性率,就可以平衡索引操作的读写...
  • 原则一:注意WHERE子句中的连接顺序: ORACLE采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必须在其他WHERE条件之前, 那些可以过滤掉最大数量记录的条件必须在WHERE子句的末尾. 尤其是“主键ID=?...
  • 网页头部优化建议

    2020-09-22 12:56:22
    下面小编就为大家带来一篇网页头部优化建议。小编觉得挺不错的,现在就分享给大家,也给大家做个参考。一起跟随小编过来看看吧
  •  SQLAdvisor是美团开源的一款SQL索引优化建议工具, 是由美团点评公司技术工程部DBA团队(北京)开发维护的一个分析SQL给出索引优化建议的工具。它基于MySQL原生态词法解析,结合分析SQL中的where条件、聚合条件、...
  • 一个中国“故事”:Airbnb爱彼迎「故事 」社区内容分析与优化建议.docx
  • 1)nginx进程数,建议按照cpu数目来指定,一般跟cpu核数相同或为它的倍数。 worker_processes 8; 2)为每个进程分配cpu,上例中将8个进程分配到8个cpu,当然可以多个,或者将一个进程分配到多个cpu。 worker_...
  • 今天小编就为大家分享一篇关于zookeeper服务优化的一些建议,小编觉得内容挺不错的,现在分享给大家,具有很好的参考价值,需要的朋友一起跟随小编来看看吧
  • 数据库优化之读写分离

    万次阅读 2016-11-02 15:19:43
    2 一般建议值,大约每秒一次事务的刷新及同步到磁盘,实际只到操作系统的buffer中,操作系统如果断电会导致失误丢失; #因为导数据都是人为参与的过程所以设置为2,让速度最大化完成,如果出错再手动搞一次即可。 ...

    前言
    网站发展的初期,由于没有太多访问量,一般来讲只需要一台服务器就够了,这时候应用软件、数据库、文件等所有资源都在一台服务器上。随着用户量和数据文件的增加,单台服务器的性能达到瓶颈,这时候需要把应用软件、数据库和文件资源单独拆分出来,满足他们对服务器硬件资源的不同需求。比如应用软件更多的需要CPU,数据库对磁盘读写多,需要快速的磁盘和充足的内存。随着业务量的再次增加,这时候需要搭建服务器集群来缓解压力,提升网站的性能,应用服务器通过软件或硬件的方式来实现负载均衡,以此来改善负载压力。数据库服务器则从单台到多台,利用主从,读写分离缓存等技术来打破数据瓶颈。
    全文数据库默认为mysql


    一 优化思路及过程
    数据库的优化顺序要根据网站场景具体分析,通常为以下优化过程
    1、服务器配置优化
    1)服务器硬件升级是所有优化方案的前提,一般来讲SQL本身的执行速度都不会太慢,慢主要是需要从磁盘把结果集读入到内存,比如改动大表时Copying to tmp table on disk这种状态常常占据很大比例时间。所以对于单个数据库,优化的次序一般是RAM、高速硬盘、CPU能力。
    2)大多网站的MySQL是IO密集型的,如果你的MySQL是个CPU密集型的话,那么很可能你的MySQL参数配置需要优化了。 针对mysql不同的引擎参数配置优化也有所不同
    INNODB表的优化
    innodb_buffer_pool_size
    主要存放热数据,按照page来存放,page为最小单位,甚至是按段来存放
    建议值: 如果是专用数据库server 建议分到物理内存的50% -- 75% 
    max_heap_table_size,tmp_table_size
    此变量定义了用户可以创建的内存表(memory table)的大小.如果内存临时表超出了限制,MySQL就会自动地把它转化为基于磁盘的表,存储在指定的tmpdir目录下。tmp_table_size 和 max_heap_table_size 大小要一致
    innodb_flush_log_at_trx_commit
    如果在导数据,可能是2天或者3天也没有导完,那么可能是这个参数设置为1的结果导致
    1  为每一次事务进一次刷新到磁盘,安全度高,但是性能最低,经常会导致导数据最慢
    0  每秒钟进一下事务的刷新到磁盘
    2  一般建议值,大约每秒一次事务的刷新及同步到磁盘,实际只写到操作系统的buffer中,操作系统如果断电会导致失误丢失; #因为导数据都是人为参与的过程所以设置为2,让速度最大化完成,如果出错再手动搞一次即可。
    MYISAM表的优化:
    key_buffer_size
    key_buffer_size指定索引缓冲区的大小,它决定索引处理的速度,尤其是索引读的速度。key_buffer_size是对MyISAM表性能影响最大的一个参数,通过检查状态值Key_read_requests和Key_reads,可以知道key_buffer_size设置是否合理。比例key_reads /key_read_requests应该尽可能的低,至少是1:100,1:1000更好

    2、sql和索引的优化
    开启mysql的慢查询,查询是否是某个SQL语句占用过多资源,如果是的话,可以对SQL语句进行优化,比如优化 insert 语句、优化 group by 语句、优化 order by 语句、优化 join 语句等等。

    3、缓存技术
    搭建redis或者memcache做为缓存层,提高数据库读取速度。

    4、主从备份读写分离
    读写分离既可以通过代码程序实现,也能利用第三方工具做,提高系统负载能力。

    5、数据的垂直拆分
    垂直拆分,其实就是根据你模块的耦合度,将一个大的系统分为多个小的系统,也就是分布式系统。

    6、数据的水平拆分
    将某个访问极其频繁的表再按照某个字段的某种规则来分散到多个表之中,每个表中包含一部分数据。

    以上就是大多情况下数据库的优化顺序,读写分离是数据库优化的必经之路,所以在这里我们了解一下读写分离的功能、使用场景和一些配置。

    二 读写分离概述
    读写分离从字面意思就可以理解,就是把对数据库的读操作和写操作分离开。读写分离在网站发展初期可以一定程度上缓解读写并发时产生锁的问题,将读写压力分担到多台服务器上,通常用于读远大于写的场景。

    *读写分离的好处*
    1)数据是网站的生命,读写分离通过主从备份数据,保证了系统的冗余,保护了珍贵的数据。
    2)提高了系统性能,一定程度提高了数据库负载能力。

    *适用读写分离场景*
    1)网站初期想要缓解数据负载最简单可行的方案。
    2)服务器面对的是读远大于写的场景,并且业务能够允许时间上一些延迟。

    *读写分离实现方式*
    目前读写分离方案网上找了几个并做了对比。
    1.mycat 基于阿里的cobar改版的(比较稳定,论坛活跃)
    2.atlas 360开发的 网友说不是很稳定 (已经很久没更新)
    3.mysql-proxy mysql自带 (不是很稳定)
    4.oneproxy 比较稳定 性能也很好 (需要付费)
    5.amoeba 好像还行,有一些公司使用 (但是很久没有更新了)

    三 mycat读写分离配置
    综上所述,我选择用mycat来实现mysql的读写分离。
     
    上图的设计思路是这样的
    1.当master正常时,读操作发生在两个slave上,写操作发生在master上。master通过主从配置实时同步数据到两个slave上。
    2.当master挂了,为了数据的一致性,和master为主从关系的slave2被停止访问。这时slave1负责读和写,当master重新恢复后,slave1同步数据给master,然后再次恢复最初读写状态。


     
    为了实现上述思路,我们需要配置mysql的主从备份和主主备份,这个很简单,这里就不叙述了。
    Mycat的前期工作需要 Java 环境,ubuntu下直接apt-get就可以下载,网上教程很多,下载好java之后再配置一下jdk环境变量
    Whereis  jvm  查看jvm路径
    然后 vi /etc/profile
    export JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk-amd64  
    export CLASSPATH=.:$JAVA_HOME/lib:$JAVA_HOME/jre/lib:$CLASSPATH  
    export PATH=$JAVA_HOME/bin:$JAVA_HOME/jre/bin:$PATH  
     
    接着 source /etc/profile 使配置生效
    配置好jdk环境变量后就可以下载mycat了
    在mycat 官网就可以下载各种版本,我下载的是 Mycat-server-1.5-release版本
     
    Mycat的配置文件主要是conf下的schema.xml,rule.xml,server.xml。
     
    我只是简单的配置了mysql的读写分离,分片分库这些功能并没有使用,所以我只配置了schema.xml和server.xml这两个文件
     
    Server.xml 文件是mycat的登录信息,我修改了以下配置
     <user name="test">   mycat登录用户名
                    <property name="password">test</property>mycat登录密码  
                    <property name="schemas">test,test1 (有多个 数据库 可以添加多个逻辑库) </property>  
            </user>                                           
                                                                                                                                                   
            <user name="user">
                    <property name="password">user</property>
                    <property name="schemas">test</property>
                    <property name="readOnly">true</property>
            </user>
     
     
    Schema.xml 文件里有mycat分库分片和读写分离的配置
    <?xml version="1.0"?>
    <!DOCTYPE mycat:schema SYSTEM "schema.dtd">
    <mycat:schema xmlns:mycat="http://org.opencloudb/" >
     
            <schema name=" test " checkSQLschema="false" sqlMaxLimit="100" dataNode="dn1">     这里的test名字要和server里的一致
           <schema name="test1" checkSQLschema="false" sqlMaxLimit="100" dataNode="dn2">
         
            <dataNode name="dn1" dataHost="localhost1" database="test" />
            <dataNode name="dn2" dataHost="localhost1" database="test1" />
         
            <dataHost name="localhost1" maxCon="1000" minCon="10" balance="1"
                    writeType="0" dbType="mysql" dbDriver="native" switchType="1"  slaveThreshold="100">
                    <heartbeat>select user()</heartbeat>
                   
                    <writeHost host="hostM1" url="localhost:3306" user="root"
                            password="">
                       </writeHost>
                    <writeHost host="hostS1" url="192.168.1.1:3306" user="root"
                            password="" />
                  
            </dataHost>
            
    </mycat:schema>
     
     这里我把注释文件全都删除了,因为我只需要实现读写分离,所以配置比较简单。
     这里需要注意的是 balance, switchType, writeType

    balance="0", 不开启读写分离机制,所有读操作都发送到当前可用的writeHost上。
    balance="1",全部的readHost与stand by writeHost参与select语句的负载均衡,简单的说,当双主双从模式(M1->S1,M2->S2,并且M1与M2互为主备),正常情况下,M2,S1,S2都参与select语句的负载均衡。
    balance="2",所有读操作都随机的在writeHost、readhost上分发。
    balance="3",所有读请求随机的分发到wiriterHost对应的readhost执行,writerHost不负担读压力
    writeType表示写模式
    writeType="0",所有的操作发送到配置的第一个writehost
    writeType="1",随机发送到配置的所有writehost
    writeType="2",不执行写操作
    switchType指的是切换的模式,目前的取值也有4种:
    switchType=‘-1‘ 表示不自动切换
    switchType=‘1‘ 默认值,表示自动切换
    switchType=‘2‘ 基于MySQL主从同步的状态决定是否切换,心跳语句为show slave status
    switchType=‘3‘基于MySQL galary cluster的切换机制(适合集群)(1.4.1),心跳语句为show status like ‘wsrep%‘。
    我上面的配置是实现的两个mysql都参与读操作,写操作只在hostm上进行,当hostm挂掉之后在hosts上进行。
     
    完成后进入bin文件,./mycat start 启动mycat
     
    如果只是实现读写分离,mycat的配置文件还是比较简单的,不过有几点需要注意。
     
    1)确定上面mysql用户是否有远程登录的权限
    2)mycat有两个端口,一个是8066,一个是9066,其中9066是管理端口,8066是数据端口,我之前一直登录管理端口,show  tables;时不能成功执行,后来才发现登录8066才行。

    遇到的问题和总结
    1)在优化的过程中,通过给予合适的mysql参数配置解决了数据库cpu密集,假死的问题。
    2)mycat读写分离架构中读数据库使用myisam引擎,然而myisam引擎面对长查询和复杂查询不能体现出优越的查询速度。所以使用myisam引擎作为读服务器还有待继续考虑。
    3)至此,mycat读写分离就配置完成了,不过以上的架构还有一个mycat单点问题,可以通过LVS+Keepalived搭建MYCAT的高可用负载集群。读写分离只是负载了读写的压力,如果想再次提升数据库的性能就要进行数据垂直和水平拆分的操作了。










    展开全文
  • 冰河亲历的亿级流量下的MySQL优化实战,强烈建议收藏!!

    大家好,我是冰河~~

    很多小伙伴留言说让我写一些工作过程中的真实案例,写些啥呢?想来想去,写一篇我在以前公司从零开始到用户超千万的数据库架构升级演变的过程吧。

    本文记录了我之前初到一家创业公司,从零开始到用户超千万,系统压力暴增的情况下是如何一步步优化MySQL数据库的,以及数据库架构升级的演变过程。升级的过程极具技术挑战性,也从中收获不少。希望能够为小伙伴们带来实质性的帮助。

    如果文章对大家有点帮助,小伙伴们点赞,收藏,评论,分享走起呀~~

    业务背景

    我之前呆过一家创业工作,是做商城业务的,商城这种业务,表面上看起来涉及的业务简单,包括:用户、商品、库存、订单、购物车、支付、物流等业务。但是,细分下来,还是比较复杂的。这其中往往会牵扯到很多提升用户体验的潜在需求。例如:为用户推荐商品,这就涉及到用户的行为分析和大数据的精准推荐。如果说具体的技术的话,那肯定就包含了:用户行为日志埋点、采集、上报,大数据实时统计分析,用户画像,商品推荐等大数据技术。

    公司的业务增长迅速,仅仅2年半不到的时间用户就从零积累到千万级别,每天的访问量几亿次,高峰QPS高达上万次每秒。数据的写压力来源于用户下单,支付等操作,尤其是赶上双十一大促期间,系统的写压力会成倍增长。然而,读业务的压力会远远大于写压力,据不完全统计,读业务的请求量是写业务的请求量的50倍左右。

    接下来,我们就一起来看看数据库是如何升级的。

    最初的技术选型

    作为创业公司,最重要的一点是敏捷,快速实现产品,对外提供服务,于是我们选择了公有云服务,保证快速实施和可扩展性,节省了自建机房等时间。整体后台采用的是Java语言进行开发,数据库使用的MySQL。整体如下图所示。
    在这里插入图片描述

    读写分离

    随着业务的发展,访问量的极速增长,上述的方案很快不能满足性能需求。每次请求的响应时间越来越长,比如用户在H5页面上不断刷新商品,响应时间从最初的500毫秒增加到了2秒以上。业务高峰期,系统甚至出现过宕机。在这生死存亡的关键时刻,通过监控,我们发现高期峰MySQL CPU使用率已接近80%,磁盘IO使用率接近90%,slow query(慢查询)从每天1百条上升到1万条,而且一天比一天严重。数据库俨然已成为瓶颈,我们必须得快速做架构升级。

    当Web应用服务出现性能瓶颈的时候,由于服务本身无状态,我们可以通过加机器的水平扩展方式来解决。 而数据库显然无法通过简单的添加机器来实现扩展,因此我们采取了MySQL主从同步和应用服务端读写分离的方案。

    MySQL支持主从同步,实时将主库的数据增量复制到从库,而且一个主库可以连接多个从库同步。利用此特性,我们在应用服务端对每次请求做读写判断,若是写请求,则把这次请求内的所有DB操作发向主库;若是读请求,则把这次请求内的所有DB操作发向从库,如下图所示。

    在这里插入图片描述

    实现读写分离后,数据库的压力减少了许多,CPU使用率和IO使用率都降到了5%以内,Slow Query(慢查询)也趋近于0。主从同步、读写分离给我们主要带来如下两个好处:

    • 减轻了主库(写)压力:商城业务主要来源于读操作,做读写分离后,读压力转移到了从库,主库的压力减小了数十倍。

    • 从库(读)可水平扩展(加从库机器):因系统压力主要是读请求,而从库又可水平扩展,当从库压力太时,可直接添加从库机器,缓解读请求压力。

    当然,没有一个方案是万能的。读写分离,暂时解决了MySQL压力问题,同时也带来了新的挑战。业务高峰期,用户提交完订单,在我的订单列表中却看不到自己提交的订单信息(典型的read after write问题);系统内部偶尔也会出现一些查询不到数据的异常。通过监控,我们发现,业务高峰期MySQL可能会出现主从复制延迟,极端情况,主从延迟高达数秒。这极大的影响了用户体验。

    那如何监控主从同步状态?在从库机器上,执行show slave status,查看Seconds_Behind_Master值,代表主从同步从库落后主库的时间,单位为秒,若主从同步无延迟,这个值为0。MySQL主从延迟一个重要的原因之一是主从复制是单线程串行执行(高版本MySQL支持并行复制)。

    那如何避免或解决主从延迟?我们做了如下一些优化:

    • 优化MySQL参数,比如增大innodb_buffer_pool_size,让更多操作在MySQL内存中完成,减少磁盘操作。
    • 使用高性能CPU主机。
    • 数据库使用物理主机,避免使用虚拟云主机,提升IO性能。
    • 使用SSD磁盘,提升IO性能。SSD的随机IO性能约是SATA硬盘的10倍甚至更高。
    • 业务代码优化,将实时性要求高的某些操作,强制使用主库做读操作。
    • 升级高版本MySQL,支持并行主从复制。

    垂直分库

    读写分离很好的解决了读压力问题,每次读压力增加,可以通过加从库的方式水平扩展。但是写操作的压力随着业务爆发式的增长没有得到有效的缓解,比如用户提交订单越来越慢。通过监控MySQL数据库,我们发现,数据库写操作越来越慢,一次普通的insert操作,甚至可能会执行1秒以上。

    另一方面,业务越来越复杂,多个应用系统使用同一个数据库,其中一个很小的非核心功能出现延迟,常常影响主库上的其它核心业务功能。这时,主库成为了性能瓶颈,我们意识到,必需得再一次做架构升级,将主库做拆分,一方面以提升性能,另一方面减少系统间的相互影响,以提升系统稳定性。这一次,我们将系统按业务进行了垂直拆分。如下图所示,将最初庞大的数据库按业务拆分成不同的业务数据库,每个系统仅访问对应业务的数据库,尽量避免或减少跨库访问。
    在这里插入图片描述

    垂直分库过程,我们也遇到不少挑战,最大的挑战是:不能跨库join,同时需要对现有代码重构。单库时,可以简单的使用join关联表查询;拆库后,拆分后的数据库在不同的实例上,就不能跨库使用join了。

    例如,通过商家名查询某个商家的所有订单,在垂直分库前,可以join商家和订单表做查询,也可以直接使用子查询,如下如示:

    select * from tb_order where supplier_id in (select id from supplier where name=’商家名称’)

    分库后,则要重构代码,先通过商家名查询商家id,再通过商家id查询订单表,如下所示:

    select id from supplier where name=’商家名称’
    select * from tb_order where supplier_id in (supplier_ids )
    

    垂直分库过程中的经验教训,使我们制定了SQL最佳实践,其中一条便是程序中禁用或少用join,而应该在程序中组装数据,让SQL更简单。一方面为以后进一步垂直拆分业务做准备,另一方面也避免了MySQL中join的性能低下的问题。

    经过近十天加班加点的底层架构调整,以及业务代码重构,终于完成了数据库的垂直拆分。拆分之后,每个应用程序只访问对应的数据库,一方面将单点数据库拆分成了多个,分摊了主库写压力;另一方面,拆分后的数据库各自独立,实现了业务隔离,不再互相影响。

    水平分库

    读写分离,通过从库水平扩展,解决了读压力;垂直分库通过按业务拆分主库,缓存了写压力,但系统依然存在以下隐患:

    • 单表数据量越来越大。如订单表,单表记录数很快就过亿,超出MySQL的极限,影响读写性能。
    • 核心业务库的写压力越来越大,已不能再进一次垂直拆分,此时的系统架构中,MySQL 主库不具备水平扩展的能力。

    此时,我们需要对MySQL进一步进行水平拆分。

    在这里插入图片描述

    水平分库面临的第一个问题是,按什么逻辑进行拆分。一种方案是按城市拆分,一个城市的所有数据在一个数据库中;另一种方案是按订单ID平均拆分数据。按城市拆分的优点是数据聚合度比较高,做聚合查询比较简单,实现也相对简单,缺点是数据分布不均匀,某些城市的数据量极大,产生热点,而这些热点以后可能还要被迫再次拆分。按订单ID拆分则正相反,优点是数据分布均匀,不会出现一个数据库数据极大或极小的情况,缺点是数据太分散,不利于做聚合查询。比如,按订单ID拆分后,一个商家的订单可能分布在不同的数据库中,查询一个商家的所有订单,可能需要查询多个数据库。针对这种情况,一种解决方案是将需要聚合查询的数据做冗余表,冗余的表不做拆分,同时在业务开发过程中,减少聚合查询。

    经过反复思考,我们最后决定按订单ID做水平分库。从架构上,将系统分为三层:

    • 应用层:即各类业务应用系统
    • 数据访问层:统一的数据访问接口,对上层应用层屏蔽读写分库、分表、缓存等技术细节。
    • 数据层:对DB数据进行分片,并可动态的添加shard分片。

    水平分库的技术关键点在于数据访问层的设计,数据访问层主要包含三部分:

    • 分布式缓存
    • 数据库中间件
    • 数据异构中间件

    而数据库中间件需要包含如下重要的功能:

    • ID生成器:生成每张表的主键
    • 数据源路由:将每次DB操作路由到不同的分片数据源上

    ID生成器

    ID生成器是整个水平分库的核心,它决定了如何拆分数据,以及查询存储-检索数据。ID需要跨库全局唯一,否则会引发业务层的冲突。此外,ID必须是数字且升序,这主要是考虑到升序的ID能保证MySQL的性能(若是UUID等随机字符串,在高并发和大数据量情况下,性能极差)。同时,ID生成器必须非常稳定,因为任何故障都会影响所有的数据库操作。

    我们系统中ID生成器的设计如下所示。

    在这里插入图片描述

    • 整个ID的二进制长度为64位
    • 前36位使用时间戳,以保证ID是升序增加
    • 中间13位是分库标识,用来标识当前这个ID对应的记录在哪个数据库中
    • 后15位为自增序列,以保证在同一秒内并发时,ID不会重复。每个分片库都有一个自增序列表,生成自增序列时,从自增序列表中获取当前自增序列值,并加1,做为当前ID的后15位
    • 下一秒时,后15位的自增序列再次从1开始。

    水平分库是一个极具挑战的项目,我们整个团队也在不断的迎接挑战中快速成长。

    为了适应公司业务的不断发展,除了在MySQL数据库上进行相应的架构升级外,我们还搭建了一套完整的大数据实时分析统计平台,在系统中对用户的行为进行实时分析。

    关于如何搭建大数据实时分析统计平台,对用户的行为进行实时分析,我们后面再详细介绍。

    写在最后

    如果你想进大厂,想升职加薪,或者对自己现有的工作比较迷茫,都可以私信我交流,希望我的一些经历能够帮助到大家~~

    推荐阅读:

    好了,今天就到这儿吧,小伙伴们点赞、收藏、评论,一键三连走起呀,我是冰河,我们下期见~~

    展开全文
  • Oracle采用自下而上的顺序解析WHERE字据,从优化性能角度考虑,建议将那些可以过滤掉大量记录行的条件在WHERE子句的末尾,而将表 之间的连接条件置于其他WHERE子句之前,即对易排查的条件先做判断处理,这样在过滤...
  • nginx指令中的优化(配置文件) 代码如下:worker_processes 8;  nginx进程数,建议按照cpu数目来指定,一般为它的倍数。 代码如下:worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 ...
  • 性能优化一般包含:数据聚合优化、资源冲突优化、算法优化、JVM优化、复用优化、计算优化和快速优化,冰河吐血整理,建议大家收藏!!

    大家好,我是冰河~~

    随着互联网的高速发展,互联网行业已经从IT时代慢慢步入到DT时代。对于Java程序员的要求越来越高,只是单纯的掌握CRUD以不足以胜任互联网公司的相关职位,大量招聘岗位显示:如果是面试中高级的Java岗,基本上都需要懂性能优化的相关知识。今天,我们就一起来聊聊如何进行性能优化这个话题。

    小伙伴们如果觉得文章不错,点赞、收藏、评论,分享走一起呀,记得给冰河来个一键三连~~

    好了,我们开始今天的正文。

    性能优化有哪些方面?

    这里,我结合平时工作中的总结,将性能优化总结为下面这张图。

    在这里插入图片描述

    也就是说,我们可以从数据聚合优化、资源冲突优化、算法优化、JVM优化、复用优化、计算优化和快速实现等方面来进行回答。接下来,我们就针对每个点进行说明。

    数据聚合优化

    数据聚合优化主要针对的是对于数据的整合和传输的优化。比如:我们从数据库中查询出的数据,经过程序的聚合处理后再返回给客户端,而不用客户端调用多次接口来分别获取数据。

    再比如:我们在项目中使用的Nginx,一般都会开启GZIP压缩,使传输的数据更加紧凑,同时,使传输的数据量更小。

    细心的小伙伴会发现,我们对于数据聚合的优化,主要是使传输的数据量更小。所以,我们在使用SQL语句查询数据库中的数据时,尽量查询那些需要的字段,对于不需要的字段就直接忽略不查询了,避免在SQL语句中出现select *

    资源冲突优化

    在我们平时的工作中,尤其是在高并发的场景下,经常会出现锁冲突的问题,锁冲突是资源冲突的一个典型场景。

    关于锁我们可以联想到数据库的行锁、表锁、Java中的synchronized和Lock等。如果对应到操作系统级别,则会有CPU命令级别的锁,JVM指令级别的锁,操作系统的内部锁等。

    这里,小伙伴们需要注意一点:只有在并发的场景下,才会出现资源冲突的问题。也就是说:在同一时刻,只能有一个请求获取到请求资源,解决冲突的方式就是加锁。

    我们需要在平时的工作过程中避免锁冲突的问题,优化如何优化加锁方式,小伙伴们可以参见《【高并发】面试官:讲讲高并发场景下如何优化加锁方式?》一文。

    算法优化

    在一个大型的互联网项目中,往往涉及到分布式和微服务等技术,其中,也会使用到大量的数据结构和算法,对于算法的优化能够显著的提高系统的性能。一个好的实现,相比于一个拙劣的实现来说,在系统性能的提升上存在着巨大的差异。

    比如,作为 List 的实现,LinkedList 和 ArrayList 在随机访问的性能上,差了好几个数量级;又比如,CopyOnWriteList 采用写时复制的方式,可以显著降低读多写少场景下的锁冲突。而什么时候使用同步,什么时候是线程安全的,也对我们的编码能力有较高的要求。

    所以,我们需要在平时工作过程中,多多积累数据结构和算法的相关知识。

    JVM优化

    JVM调优,不用说,这是每个Java工程师必须要掌握的标准技能。所有的Java程序最终都是运行在JVM中的,对JVM进行优化也能够提升Java程序的性能。但是,需要注意的是:如果在优化JVM时,参数设置不当,可能会造成内存溢出等严重的问题。

    目前被广泛使用的垃圾回收器是 G1,通过很少的参数配置,内存即可高效回收。CMS 垃圾回收器已经在 Java 14 中被移除,由于它的 GC 时间不可控,有条件应该尽量避免使用。

    复用优化

    复用优化,这个看名字就知道,说白了就是可以重复利用。估计很多小伙伴都有这样的经验,在写代码的时候,可以将很多重复的代码抽象出来,做成公共的方法。这样,就不用每次都去写重复的逻辑代码了。这是代码层面的复用。

    如果是数据层面的话,我们可以使用缓冲和缓存来复用数据。

    这里,小伙伴们需要注意一个知识点:缓冲主要针对的是写操作,缓存主要针对的是读操作。

    另一个复用优化的典型场景就是池化技术,比如:数据库连接池、线程池等。

    计算优化

    对于计算优化来说,我们可以从以下几个小的方面来阐述。

    并行计算

    不难理解,就是多个计算同时进行。这里,又可以将并行计算分为:多机并行计算、多进程并行计算和多线程并行计算。

    多机并行计算: 将一个大的计算任务,拆分成N个小的计算任务,分发到不同的机器进行处理。典型的场景就是Hadoop的MapReduce极端。

    多进程计算: 比如,Nginx采用的NIO模型,采用的是进程调度的策略,由Master进程调度Worker进程,Worker进行来处理具体的请求。

    多线程计算: 对于多线程计算来说,也是我们平时接触最多的一种计算方式,我们可以使用多线程技术,将复杂的逻辑计算拆分成一个个小的计算任务,分发到不同的线程中去执行。

    同步变异步

    同步和异步的区别就是:同步需要等待返回结果,异步不需要等待返回结果。如果我们在业务程序中,不需要等待返回结果数据,则我们可以将同步调用优化为异步调用,从而提升我们系统的性能。

    懒加载

    最典型的场景就是Spring中的懒加载,只有第一次获取bean的时候,才会创建bean实例。

    快速实现

    对于快速实现来说,不仅包含我们需要利用相关的程序框架迅速开发出我们想要的业务,也需要我们在进行技术选型时,尽量使用一些性能优良的组件。比如,在进行网络开发时,尽量选择Netty,结合轻量级的数据传输,就不要使用WebService等技术了。

    很多公司喜欢使用适配器模式,在一些现有的开源组件之上,再抽象一层自己的组件,这样就能够做到切换底层组件的时候,对上层应用无感。

    写在最后

    如果你想进大厂,想升职加薪,或者对自己现有的工作比较迷茫,都可以私信我交流,希望我的一些经历能够帮助到大家~~

    推荐阅读:

    好了,今天就到这儿吧,小伙伴们点赞、收藏、评论,一键三连走起呀,我是冰河,我们下期见~~

    展开全文
  • 主要介绍了CSS图片优化的一些相关建议,主要针对Sprites图片整合技术来作简单介绍,需要的朋友可以参考下
  • 随着后端优化空间越来越小,现在越来越多的网站更注重前端性能的优化,就是浏览器,http层面的优化,这里两点最简单最有效的 asp.net网站优化技巧。 了解常见的网站性能优化技巧 首先我们要学一些优化网站性能和...
  • CSS常用优化技巧

    2020-12-13 15:39:48
    一.使用css缩写 使用缩写可以帮助减少你CSS文件的大小,更加容易阅读。css缩写的主要规则请参看《常用css缩写语法总结》,这里就不展开描述。 ...为了避免这种错误,我建议所有的定义名称都采用小
  • 作为性能优化专栏的第五篇,阅读本文章前可以先阅读 (四)内存优化前奏篇(Java虚拟机、垃圾回收机制、内存泄漏/溢出/抖动,再阅读本篇文章效果更佳。 本篇文章就来讲一下在项目中如何使用工具来分析内存泄漏。 ...
  • 人工智能的本质就是最优化。假设把任务比作是一碗饭, 传统的解决方法,就是根据数学公式,然后一口气吃完饭,如果饭碗小,数学公式还行,如果饭碗大,数学公式能一口吃完饭吗? 人工智能的本质就是有很多优化算法,...
  • 不错的谷歌优化建议,值得收藏,不过是全英文的,下载的朋友们要有心理准备啊
  • 项目实施过程中的优化建议

    千次阅读 2017-02-07 13:44:00
    2015年9月,我在一间上市公司的子公司任职测试组长,参与公司项目群会议时,针对项目的问题提出优化建议如下: 一、公司通用的商城项目: 个人觉得主要从 计划、实施、沟通协作、建设提高 这些方面考虑。 1、是...
  • 如何优化MySQL千万级大表,我了6000字的解读

    万次阅读 多人点赞 2019-10-21 20:03:03
    千万级大表如何优化,这是一个很有技术含量的问题,通常我们的直觉思维都会跳转到拆分或者数据分区,在此我想做一些补充和梳理,想和大家做一些这方面的经验总结,也欢迎大家提出建议。 从一开始脑海里开始也是...
  • uniapp性能优化建议

    千次阅读 2021-07-07 10:04:40
    性能优化是每个项目都必须重视的,所以在使用uniapp中,将一些性能优化的点记录下来,在代码的时候需要注意一下: 一、优化数据更新  在uni-app中,定义在 data 里面的数据每次变化时都会通知视图层重新渲染...
  • HBase性能优化策略

    千次阅读 2017-11-13 10:20:21
    一 HBase写入性能优化 1.1 是否需要WAL? WAL是否需要同步? WAL机制可以确保数据即使写入缓存的数据丢失了,也可以恢复;另外是为了集群之间的异步复制。默认WAL机制开启,且使用同步机制写入WAL. 我们可以...
  • 深度学习 优化和识别

    2019-03-07 10:12:17
    里面存着 深度学习、优化与识别.焦李成(详细书签), 建议学习的时候一边看 一边代码 感受, 只有实战才能出经验
  • Android性能优化之页面优化

    千次阅读 2022-03-03 14:03:32
    通过原理,实战的角度,带读者了解如何进行安卓的界面性能优化
  • WPF 性能优化建议

    千次阅读 2019-04-12 10:10:25
    本章讲述:WPF 性能优化建议 20180930 WPF性能优化问题:运行软件发现CPU使用率很大(80%-95%),程序中含有委托,线程,定时器的处理,之前优化时,主要优化线程和定时器相关线程方面的处理,但是效果甚微; 无意...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 458,195
精华内容 183,278
热门标签
关键字:

优化建议怎么写