牙小木木

牙小木木 查看完整档案

北京编辑  |  填写毕业院校  |  填写所在公司/组织 tuber.github.io 编辑
编辑

iamtb.cn

个人动态

牙小木木 发布了文章 · 2月20日

如何在Php中获得一个Final类的Protected的static成员属性

<?php 
final class ConstantOne {
  static protected $ERRNO_OK;
  static protected function init_ERRNO_OK() {
    return 0;
  }
  static protected function init_ErrorMsg() {
    return array(
      0 => "OK",
    );
  }
}

请答题:

如何获取'0'?

错误方式1

class test extends ConstantOne{

}
ECHO test::init_ERRNO_OK();

方式1原因:

PHP Fatal error: Class test may not inherit from final class (ConstantOne)

错误方式2

var_dump(ConstantOne::init_ErrorMsg());
方式2原因:

PHP Fatal error: Uncaught Error: Call to protected method ConstantOne::init_ErrorMsg()

思考

staitc的话,我可以不实例化就可以调用,protected的话,可以实例化本类或者父类调用,但是关键是还有个final修饰。Final修饰的类不能被继承,所以只能本类调用,未实例的类调用static的方法又说是因为protected的。static本质是类的方法,

解决思路

/**
 * Base class for constant Management
 */
abstract class BaseConstant
{
    /**
     * Don't instanciate this class
     */
    protected function __construct() {}

    /**
     * Get a constant value
     * @param string $constant
     * @return mixed
     */
    public static function get($constant)
    {
        if(is_null(static::$$constant))
        {
            // echo sprintf('static::init_%s', $constant);
            static::$$constant = call_user_func(
                    sprintf('static::init_%s', $constant)
                );
        }

        return static::$$constant;
    }
}

final class ConstantTwo extends BaseConstant {
  static protected $ERRNO_OK;
  static protected function init_ERRNO_OK() {
    return 100;
  }
  static protected function init_ErrorMsg() {
    return array(
      100 => "OK",
    );
  }

//以下这也也可以
  public static function outOK (){
      echo static::init_ERRNO_OK();
  }
}

echo ConstantTwo::get('ERRNO_OK');

echo ConstantTwo::outOK();
查看原文

赞 0 收藏 0 评论 0

牙小木木 赞了文章 · 2月18日

滴滴陶文:我眼中的技术深度

出品 | 滴滴技术
作者 | 陶文

图片描述
前言:本文来自陶文老师在内部发布的话题分享,引发了技术桔们的热议,桔妹在此与大家分享该话题,期待大家看完陶老师的解读,在文末分享自己对技术深度的看法。

经常有同学被挑战工作没有技术深度。不少日常写业务的同学会顿时紧张起来。开始在脑袋里找各种证据证明自己干过的啥事情“有难度的”。

其实这个问题如果准备一下,就不至于慌张了。在我看来,技术深度可以从下面这张图推导而来:

图片描述

技术同学的主要工作是构建一个可运行的 solution 去解决用户的一个 problem。以这个为主题,有两件工作:

运营维护这个 solution,持续去解决 problem。

洞察到 problem 本身的变化,或者有更好的 solution。然后把现有的solution迁移成一个新的 solution 去更好的解决 problem。

技术深度就体现在“更好”地完成这两项工作上,也就是一个优化问题:

▍对运营维护工作而言

降低运营的人工成本:例如自动化代替人工。

降低运营的其他成本:例如更少的机器投入,例如稳定性和安全建设减少风险。

▍对研发工作而言

对 new problem 或者 new solution 的洞察力:数据分析,市场调研,新技术跟进等。提升 solution 对用户的吸引力。新体验-旧体验-迁移成本。

短期敏捷性:因为对 api 很熟悉,能够快速rush出一个版本来的能力。因为对环境很熟悉,可以快速定位 bug 的能力等。

长期敏捷性:架构设计,复杂度管理等。

提供独特 solution 的能力:比如说自动驾驶等科技。从 0 到 1 的过程可以最大化对用户的吸引力,因为很少人提供竞争 solution。

▍每一项优化工作,都可以做得很深

比如你可以投入大量时间学习数据库原理,优化索引检索的效率,从而降低运营的其他成本。

你也可以构建流量录制和回放技术,提供对重构工作的信心保障。从而提高长期敏捷性。

你也可以打磨对产品的洞察力。精通数据分析,倾听用户,对产品的未来演进方向提供自己的洞察。

你也可以锻炼自己快速 debug 的能力,可以在 crash 之后快速用各种工具找到性能瓶颈。这个算是短期敏捷性上的能力。主要是考验对环境和生态是否熟悉。所谓经验活。

其实评委在问你技术深度的时候,并不是问你技术栈的深度(比如是否从像素渲染到硅的提纯都了然于胸),真正在问的是你的竞争力在哪里。

▍你需要想清楚两点

为什么在这个点上,我做过的工作证明了比其他同事要更强。

为什么这个能力是当前公司需要的,也就是所谓的收益。你能手写汇编构造 GUI,但是公司不需要也是没有用的“技术深度”。

希望下次你被问到技术深度问题的时候,能够从容回答。

图片描述

陶文:滴滴 | 首席工程师
在滴滴参与过基础架构,核心出行平台重构,业务中台建设等工作,目前在从事平台治理和客服系统,致力于减少大家出行中遇到的不美好。在加入滴滴之前,从事过十余年敏捷咨询,测试开发,运维平台等多个领域的工作。

图片描述

查看原文

赞 5 收藏 3 评论 0

牙小木木 关注了用户 · 2月18日

滴滴技术 @didijishu

滴滴出行技术官方号

关注 1847

牙小木木 赞了文章 · 2月13日

12306抢票带来的启示:看我如何用Go实现百万QPS的秒杀系统

本文为开源实验性工程:“github.com/GuoZhaoran/spikeSystem”的配套文章,原作者:“绘你一世倾城”,现为:猎豹移动php开发工程师,感谢原作者的技术分享。

1、引言

Go语言的出现,让开发高性能、高稳定性服务端系统变的容易,与高贵冷艳的Erlang语言不同的是,Go语言简单易学,在高性能服务端架构中的应用越来越广泛。

对于即时通讯(IM系统、消息推送系统等高性能实时通信等)等场景下,Go语言已经被越来越多的用于核心通信模块中。本文内容虽是从秒杀系统谈起,并未直接涉及即时通讯相关知识,但有关Go的高并发实践,仍然值得广大即时通讯技术爱好者们研究和学习,必竟业务可以不同,但技术都是相通的,或许能为你即时通讯系统的高并发架构带来新的思路和灵感。技多不压身,杀望对你有所帮助!

本文所述并非纯理论水文,均以已付实践,配套源码请见:

1)主要地址:https://github.com/GuoZhaoran/spikeSystem
2)备用地址:https://github.com/52im/spikeSystem

友情提示:本文适合有一定高并发服务端设计经验的开发者阅读,如您对这方面知识了解太少,请务必先按序阅读以下文章:

新手入门:零基础理解大型分布式架构的演进历史、技术原理、最佳实践
一篇读懂分布式架构下的负载均衡技术:分类、原理、算法、常见方案等
从新手到架构师,一篇就够:从100到1000万高并发的架构演进之路
腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面
快速理解高性能HTTP服务端的负载均衡技术原理

(本文同步发布于:http://www.52im.net/thread-2771-1-1.html

2、12306抢票,极限并发带来的思考

虽然现在大多数情况下都能订到票,但是放票瞬间即无票的场景,相信大家都深有体会。

尤其是春节期间,大家不仅使用 12306,还会考虑“智行”和其他的抢票软件,全国上下几亿人在这段时间都在抢票。

“12306 服务”承受着这个世界上任何秒杀系统都无法超越的 QPS,上百万的并发再正常不过了!

笔者专门研究了一下“12306”的服务端架构,学习到了其系统设计上很多亮点,在这里和大家分享一下并模拟一个例子:如何在 100 万人同时抢 1 万张火车票时,系统提供正常、稳定的服务。

3、大型高并发系统架构

高并发的系统架构都会采用分布式集群部署,服务上层有着层层负载均衡,并提供各种容灾手段(双火机房、节点容错、服务器灾备等)保证系统的高可用,流量也会根据不同的负载能力和配置策略均衡到不同的服务器上。

下边是一个简单的示意图:

3.1 负载均衡简介

上图中描述了用户请求到服务器经历了三层的负载均衡,下边分别简单介绍一下这三种负载均衡。

① OSPF(开放式最短链路优先)是一个内部网关协议(Interior Gateway Protocol,简称 IGP)

OSPF 通过路由器之间通告网络接口的状态来建立链路状态数据库,生成最短路径树,OSPF 会自动计算路由接口上的 Cost 值,但也可以通过手工指定该接口的 Cost 值,手工指定的优先于自动计算的值。

OSPF 计算的 Cost,同样是和接口带宽成反比,带宽越高,Cost 值越小。到达目标相同 Cost 值的路径,可以执行负载均衡,最多 6 条链路同时执行负载均衡。

② LVS (Linux Virtual Server)

它是一种集群(Cluster)技术,采用 IP 负载均衡技术和基于内容请求分发技术。

调度器具有很好的吞吐率,将请求均衡地转移到不同的服务器上执行,且调度器自动屏蔽掉服务器的故障,从而将一组服务器构成一个高性能的、高可用的虚拟服务器。

③ Nginx

想必大家都很熟悉了,是一款非常高性能的 HTTP 代理/反向代理服务器,服务开发中也经常使用它来做负载均衡。

Nginx 实现负载均衡的方式主要有三种:

1)轮询;
2)加权轮询;
3)IP Hash 轮询。

下面我们就针对 Nginx 的加权轮询做专门的配置和测试。

3.2 Nginx 加权轮询的演示

Nginx 实现负载均衡通过 Upstream 模块实现,其中加权轮询的配置是可以给相关的服务加上一个权重值,配置的时候可能根据服务器的性能、负载能力设置相应的负载。

下面是一个加权轮询负载的配置,我将在本地的监听 3001-3004 端口,分别配置 1,2,3,4 的权重:

配置负载均衡

    upstream load_rule {
       server 127.0.0.1:3001 weight=1;
       server 127.0.0.1:3002 weight=2;
       server 127.0.0.1:3003 weight=3;
       server 127.0.0.1:3004 weight=4;
    }
    ...
    server {
    listen       80;
    server_name  load_balance.com [url=http://www.load_balance.com]www.load_balance.com[/url];
    location / {
       proxy_pass http://load_rule;
    }
}

我在本地 /etc/hosts 目录下配置了 www.load_balance.com 的虚拟域名地址。

接下来使用 Go 语言开启四个 HTTP 端口监听服务,下面是监听在 3001 端口的 Go 程序,其他几个只需要修改端口即可:

package main
import(
    "net/http"
    "os"
    "strings"
)

func main() {
    http.HandleFunc("/buy/ticket", handleReq)
    http.ListenAndServe(":3001", nil)
}

//处理请求函数,根据请求将响应结果信息写入日志
func handleReq(w http.ResponseWriter, r *http.Request) {
    failedMsg :=  "handle in port:"
    writeLog(failedMsg, "./stat.log")
}

//写入日志
func writeLog(msg string, logPath string) {
    fd, _ := os.OpenFile(logPath, os.O_RDWR|os.O_CREATE|os.O_APPEND, 0644)
    defer fd.Close()
    content := strings.Join([]string{msg, "\r\n"}, "3001")
    buf := []byte(content)
    fd.Write(buf)
}

我将请求的端口日志信息写到了 ./stat.log 文件当中,然后使用 AB 压测工具做压测:

ab -n 1000 -c 100 http://www.load_balance.com/buy/ticket

统计日志中的结果,3001-3004 端口分别得到了 100、200、300、400 的请求量。

这和我在 Nginx 中配置的权重占比很好的吻合在了一起,并且负载后的流量非常的均匀、随机。

具体的实现大家可以参考 Nginx 的 Upsteam 模块实现源码,这里推荐一篇文章《Nginx 中 Upstream 机制的负载均衡》。

4、秒杀抢购系统选型

回到我们最初提到的问题中来:火车票秒杀系统如何在高并发情况下提供正常、稳定的服务呢?

从上面的介绍我们知道用户秒杀流量通过层层的负载均衡,均匀到了不同的服务器上,即使如此,集群中的单机所承受的 QPS 也是非常高的。如何将单机性能优化到极致呢?

要解决这个问题,我们就要想明白一件事:通常订票系统要处理生成订单、减扣库存、用户支付这三个基本的阶段。

我们系统要做的事情是要保证火车票订单不超卖、不少卖,每张售卖的车票都必须支付才有效,还要保证系统承受极高的并发。

这三个阶段的先后顺序该怎么分配才更加合理呢?我们来分析一下。。。

4.1 下单减库存

当用户并发请求到达服务端时,首先创建订单,然后扣除库存,等待用户支付。

这种顺序是我们一般人首先会想到的解决方案,这种情况下也能保证订单不会超卖,因为创建订单之后就会减库存,这是一个原子操作。

但是这样也会产生一些问题:

1)在极限并发情况下,任何一个内存操作的细节都至关影响性能,尤其像创建订单这种逻辑,一般都需要存储到磁盘数据库的,对数据库的压力是可想而知的;

2)如果用户存在恶意下单的情况,只下单不支付这样库存就会变少,会少卖很多订单,虽然服务端可以限制 IP 和用户的购买订单数量,这也不算是一个好方法。

4.2 支付减库存

如果等待用户支付了订单在减库存,第一感觉就是不会少卖。但是这是并发架构的大忌,因为在极限并发情况下,用户可能会创建很多订单。

当库存减为零的时候很多用户发现抢到的订单支付不了了,这也就是所谓的“超卖”。也不能避免并发操作数据库磁盘 IO。

4.3 预扣库存

从上边两种方案的考虑,我们可以得出结论:只要创建订单,就要频繁操作数据库 IO。

那么有没有一种不需要直接操作数据库 IO 的方案呢,这就是预扣库存。先扣除了库存,保证不超卖,然后异步生成用户订单,这样响应给用户的速度就会快很多;那么怎么保证不少卖呢?用户拿到了订单,不支付怎么办?

我们都知道现在订单都有有效期,比如说用户五分钟内不支付,订单就失效了,订单一旦失效,就会加入新的库存,这也是现在很多网上零售企业保证商品不少卖采用的方案。

订单的生成是异步的,一般都会放到 MQ、Kafka 这样的即时消费队列中处理,订单量比较少的情况下,生成订单非常快,用户几乎不用排队。

5、扣库存的艺术

从上面的分析可知,显然预扣库存的方案最合理。我们进一步分析扣库存的细节,这里还有很大的优化空间,库存存在哪里?怎样保证高并发下,正确的扣库存,还能快速的响应用户请求?

在单机低并发情况下,我们实现扣库存通常是这样的:

为了保证扣库存和生成订单的原子性,需要采用事务处理,然后取库存判断、减库存,最后提交事务,整个流程有很多 IO,对数据库的操作又是阻塞的。

这种方式根本不适合高并发的秒杀系统。接下来我们对单机扣库存的方案做优化:本地扣库存

我们把一定的库存量分配到本地机器,直接在内存中减库存,然后按照之前的逻辑异步创建订单。

改进过之后的单机系统是这样的:

这样就避免了对数据库频繁的 IO 操作,只在内存中做运算,极大的提高了单机抗并发的能力。

但是百万的用户请求量单机是无论如何也抗不住的,虽然 Nginx 处理网络请求使用 Epoll 模型,c10k 的问题在业界早已得到了解决。

但是 Linux 系统下,一切资源皆文件,网络请求也是这样,大量的文件描述符会使操作系统瞬间失去响应。

上面我们提到了 Nginx 的加权均衡策略,我们不妨假设将 100W 的用户请求量平均均衡到 100 台服务器上,这样单机所承受的并发量就小了很多。

然后我们每台机器本地库存 100 张火车票,100 台服务器上的总库存还是 1 万,这样保证了库存订单不超卖。

下面是我们描述的集群架构:

问题接踵而至,在高并发情况下,现在我们还无法保证系统的高可用,假如这 100 台服务器上有两三台机器因为扛不住并发的流量或者其他的原因宕机了。那么这些服务器上的订单就卖不出去了,这就造成了订单的少卖。

要解决这个问题,我们需要对总订单量做统一的管理,这就是接下来的容错方案。服务器不仅要在本地减库存,另外要远程统一减库存。

有了远程统一减库存的操作,我们就可以根据机器负载情况,为每台机器分配一些多余的“Buffer 库存”用来防止机器中有机器宕机的情况。

我们结合下面架构图具体分析一下:

我们采用 Redis 存储统一库存,因为 Redis 的性能非常高,号称单机 QPS 能抗 10W 的并发。

在本地减库存以后,如果本地有订单,我们再去请求 Redis 远程减库存,本地减库存和远程减库存都成功了,才返回给用户抢票成功的提示,这样也能有效的保证订单不会超卖。

当机器中有机器宕机时,因为每个机器上有预留的 Buffer 余票,所以宕机机器上的余票依然能够在其他机器上得到弥补,保证了不少卖。

Buffer 余票设置多少合适呢,理论上 Buffer 设置的越多,系统容忍宕机的机器数量就越多,但是 Buffer 设置的太大也会对 Redis 造成一定的影响。

虽然 Redis 内存数据库抗并发能力非常高,请求依然会走一次网络 IO,其实抢票过程中对 Redis 的请求次数是本地库存和 Buffer 库存的总量。

因为当本地库存不足时,系统直接返回用户“已售罄”的信息提示,就不会再走统一扣库存的逻辑。

这在一定程度上也避免了巨大的网络请求量把 Redis 压跨,所以 Buffer 值设置多少,需要架构师对系统的负载能力做认真的考量。

6、动手写代码

Go 语言原生为并发设计,我采用 Go 语言给大家演示一下单机抢票的具体流程。

6.1 初始化工作

Go 包中的 Init 函数先于 Main 函数执行,在这个阶段主要做一些准备性工作。

我们系统需要做的准备工作有:初始化本地库存、初始化远程 Redis 存储统一库存的 Hash 键值、初始化 Redis 连接池。

另外还需要初始化一个大小为 1 的 Int 类型 Chan,目的是实现分布式锁的功能。

也可以直接使用读写锁或者使用 Redis 等其他的方式避免资源竞争,但使用 Channel 更加高效,这就是 Go 语言的哲学:不要通过共享内存来通信,而要通过通信来共享内存。

Redis 库使用的是 Redigo,下面是代码实现:

...
//localSpike包结构体定义
packagelocalSpike

typeLocalSpike struct{
    LocalInStock     int64
    LocalSalesVolume int64
}
...
//remoteSpike对hash结构的定义和redis连接池
packageremoteSpike
//远程订单存储健值
typeRemoteSpikeKeys struct{
    SpikeOrderHashKey string//redis中秒杀订单hash结构key
    TotalInventoryKey string//hash结构中总订单库存key
    QuantityOfOrderKey string//hash结构中已有订单数量key
}

//初始化redis连接池
funcNewPool() *redis.Pool {
    return&redis.Pool{
        MaxIdle:   10000,
        MaxActive: 12000, // max number of connections
        Dial: func() (redis.Conn, error) {
            c, err := redis.Dial("tcp", ":6379")
            iferr != nil{
                panic(err.Error())
            }
            returnc, err
        },
    }
}
...
funcinit() {
    localSpike = localSpike2.LocalSpike{
        LocalInStock:     150,
        LocalSalesVolume: 0,
    }
    remoteSpike = remoteSpike2.RemoteSpikeKeys{
        SpikeOrderHashKey:  "ticket_hash_key",
        TotalInventoryKey:  "ticket_total_nums",
        QuantityOfOrderKey: "ticket_sold_nums",
    }
    redisPool = remoteSpike2.NewPool()
    done = make(chanint, 1)
    done <- 1
}

6.2 本地扣库存和统一扣库存

本地扣库存逻辑非常简单,用户请求过来,添加销量,然后对比销量是否大于本地库存,返回 Bool 值:

package localSpike
//本地扣库存,返回bool值
func(spike *LocalSpike) LocalDeductionStock() bool{
    spike.LocalSalesVolume = spike.LocalSalesVolume + 1
    returnspike.LocalSalesVolume < spike.LocalInStock
}

注意这里对共享数据 LocalSalesVolume 的操作是要使用锁来实现的,但是因为本地扣库存和统一扣库存是一个原子性操作,所以在最上层使用 Channel 来实现,这块后边会讲。

统一扣库存操作 Redis,因为 Redis 是单线程的,而我们要实现从中取数据,写数据并计算一些列步骤,我们要配合 Lua 脚本打包命令,保证操作的原子性:

package remoteSpike
......
constLuaScript = `
        local ticket_key = KEYS[1]
        local ticket_total_key = ARGV[1]
        local ticket_sold_key = ARGV[2]
        local ticket_total_nums = tonumber(redis.call('HGET', ticket_key, ticket_total_key))
        local ticket_sold_nums = tonumber(redis.call('HGET', ticket_key, ticket_sold_key))
        -- 查看是否还有余票,增加订单数量,返回结果值
       if(ticket_total_nums >= ticket_sold_nums) then
            return redis.call('HINCRBY', ticket_key, ticket_sold_key, 1)
        end
        return 0
`
//远端统一扣库存
func(RemoteSpikeKeys *RemoteSpikeKeys) RemoteDeductionStock(conn redis.Conn) bool{
    lua := redis.NewScript(1, LuaScript)
    result, err := redis.Int(lua.Do(conn, RemoteSpikeKeys.SpikeOrderHashKey, RemoteSpikeKeys.TotalInventoryKey, RemoteSpikeKeys.QuantityOfOrderKey))
    iferr != nil{
        returnfalse
    }
    returnresult != 0
}

我们使用 Hash 结构存储总库存和总销量的信息,用户请求过来时,判断总销量是否大于库存,然后返回相关的 Bool 值。

在启动服务之前,我们需要初始化 Redis 的初始库存信息:

1hmset ticket_hash_key "ticket_total_nums"10000 "ticket_sold_nums"0

6.3 响应用户信息

我们开启一个 HTTP 服务,监听在一个端口上:

package main
...
funcmain() {
    http.HandleFunc("/buy/ticket", handleReq)
    http.ListenAndServe(":3005", nil)
}

上面我们做完了所有的初始化工作,接下来 handleReq 的逻辑非常清晰,判断是否抢票成功,返回给用户信息就可以了。

package main
//处理请求函数,根据请求将响应结果信息写入日志
funchandleReq(w http.ResponseWriter, r *http.Request) {
    redisConn := redisPool.Get()
    LogMsg := ""
    <-done
    //全局读写锁
    iflocalSpike.LocalDeductionStock() && remoteSpike.RemoteDeductionStock(redisConn) {
        util.RespJson(w, 1,  "抢票成功", nil)
        LogMsg = LogMsg + "result:1,localSales:"+ strconv.FormatInt(localSpike.LocalSalesVolume, 10)
    } else{
        util.RespJson(w, -1, "已售罄", nil)
        LogMsg = LogMsg + "result:0,localSales:"+ strconv.FormatInt(localSpike.LocalSalesVolume, 10)
    }
    done <- 1

    //将抢票状态写入到log中
    writeLog(LogMsg, "./stat.log")
}

funcwriteLog(msg string, logPath string) {
    fd, _ := os.OpenFile(logPath, os.O_RDWR|os.O_CREATE|os.O_APPEND, 0644)
    deferfd.Close()
    content := strings.Join([]string{msg, "\r\n"}, "")
    buf := []byte(content)
    fd.Write(buf)
}

前边提到我们扣库存时要考虑竞态条件,我们这里是使用 Channel 避免并发的读写,保证了请求的高效顺序执行。我们将接口的返回信息写入到了 ./stat.log 文件方便做压测统计。

6.4 单机服务压测

开启服务,我们使用 AB 压测工具进行测试:

ab -n 10000 -c 100 http://127.0.0.1:3005/buy/ticket

下面是我本地低配 Mac 的压测信息:

This is ApacheBench, Version 2.3 <$Revision: 1826891 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, [url=http://www.zeustech.net/]http://www.zeustech.net/[/url]
Licensed to The Apache Software Foundation, [url=http://www.apache.org/]http://www.apache.org/[/url]

Benchmarking 127.0.0.1 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests

Server Software:
Server Hostname:        127.0.0.1
Server Port:            3005

Document Path:          /buy/ticket
Document Length:        29 bytes

Concurrency Level:      100
Time taken fortests:   2.339 seconds
Complete requests:      10000
Failed requests:        0
Total transferred:      1370000 bytes
HTML transferred:       290000 bytes
Requests per second:    4275.96 [#/sec] (mean)
Time per request:       23.387 [ms] (mean)
Time per request:       0.234 [ms] (mean, across all concurrent requests)
Transfer rate:          572.08 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    8  14.7      6     223
Processing:     2   15  17.6     11     232
Waiting:        1   11  13.5      8     225
Total:          7   23  22.8     18     239

Percentage of the requests served within a certain time(ms)
  50%     18
  66%     24
  75%     26
  80%     28
  90%     33
  95%     39
  98%     45
  99%     54
 100%    239 (longest request)

根据指标显示,我单机每秒就能处理 4000+ 的请求,正常服务器都是多核配置,处理 1W+ 的请求根本没有问题。

而且查看日志发现整个服务过程中,请求都很正常,流量均匀,Redis 也很正常:

//stat.log
...
result:1,localSales:145
result:1,localSales:146
result:1,localSales:147
result:1,localSales:148
result:1,localSales:149
result:1,localSales:150
result:0,localSales:151
result:0,localSales:152
result:0,localSales:153
result:0,localSales:154
result:0,localSales:156
...

7、本文小结

总体来说,秒杀系统是非常复杂的。我们这里只是简单介绍模拟了一下单机如何优化到高性能,集群如何避免单点故障,保证订单不超卖、不少卖的一些策略,完整的订单系统还有订单进度的查看,每台服务器上都有一个任务,定时的从总库存同步余票和库存信息展示给用户,还有用户在订单有效期内不支付,释放订单,补充到库存等等。

我们实现了高并发抢票的核心逻辑,可以说系统设计的非常的巧妙,巧妙的避开了对 DB 数据库 IO 的操作。

对 Redis 网络 IO 的高并发请求,几乎所有的计算都是在内存中完成的,而且有效的保证了不超卖、不少卖,还能够容忍部分机器的宕机。

我觉得其中有两点特别值得学习总结的。

① 负载均衡,分而治之:

通过负载均衡,将不同的流量划分到不同的机器上,每台机器处理好自己的请求,将自己的性能发挥到极致。

这样系统的整体也就能承受极高的并发了,就像工作的一个团队,每个人都将自己的价值发挥到了极致,团队成长自然是很大的。

② 合理的使用并发和异步:

自 Epoll 网络架构模型解决了 c10k 问题以来,异步越来越被服务端开发人员所接受,能够用异步来做的工作,就用异步来做,在功能拆解上能达到意想不到的效果。

这点在 Nginx、Node.JS、Redis 上都能体现,他们处理网络请求使用的 Epoll 模型,用实践告诉了我们单线程依然可以发挥强大的威力。

服务器已经进入了多核时代,Go 语言这种天生为并发而生的语言,完美的发挥了服务器多核优势,很多可以并发处理的任务都可以使用并发来解决,比如 Go 处理 HTTP 请求时每个请求都会在一个 Goroutine 中执行。

总之,怎样合理的压榨 CPU,让其发挥出应有的价值,是我们一直需要探索学习的方向。

附录:更多高并发架构设计方面的文章

[1] 通用架构设计相关文章:
腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面
快速理解高性能HTTP服务端的负载均衡技术原理
子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践
知乎技术分享:从单机到2000万QPS并发的Redis高性能缓存实践之路
新手入门:零基础理解大型分布式架构的演进历史、技术原理、最佳实践
阿里技术分享:深度揭秘阿里数据库技术方案的10年变迁史
阿里技术分享:阿里自研金融级数据库OceanBase的艰辛成长之路
达达O2O后台架构演进实践:从0到4000高并发请求背后的努力
优秀后端架构师必会知识:史上最全MySQL大表优化方案总结
小米技术分享:解密小米抢购系统千万高并发架构的演进和实践
一篇读懂分布式架构下的负载均衡技术:分类、原理、算法、常见方案等
通俗易懂:如何设计能支撑百万并发的数据库架构?
多维度对比5款主流分布式MQ消息队列,妈妈再也不担心我的技术选型了
从新手到架构师,一篇就够:从100到1000万高并发的架构演进之路
美团技术分享:深度解密美团的分布式ID生成算法
12306抢票带来的启示:看我如何用Go实现百万QPS的秒杀系统(含源码)
>> 更多同类文章 ……
[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开发基础知识补课(六):数据库用NoSQL还是SQL?读这篇就够了!
>> 更多同类文章 ……

(本文同步发布于:http://www.52im.net/thread-2771-1-1.html

查看原文

赞 43 收藏 28 评论 4

牙小木木 收藏了文章 · 2020-12-23

使用Xdebug进行远程调试

为什么要用?

  1. 方便联调:
    和客户端一起联调,是die(); exit(); 会影响其他人员是使用。
  2. 关注数据变化:
    正常情况下,我们在调试和开发时,更关注数据的变化。频繁断点、效率比较低。
  3. 简单:
    之前的开发自己比较懒,一直没用,用起来发现很简单。

原理

运行xdebug需要客户端IDE(phpstorm)、远程服务器配合,首先是客户端配置好端口,发送debug请求,请求会通过浏览器或者IDE的http请求,携带特定的参数发送到服务端,服务端收到请求后,发现这是一个xdebug请求,则与IDE建立dpgp连接,当遇到断点时候,返回调试信息给IDE

image | left

  • 服务器的IP是10.0.1.2,端口80上有HTTP
  • IDE位于未知IP上,因此xdebug.remote_connect_back设置为1
  • IDE侦听端口9000,因此xdebug.remote_port设置为9000
  • 发出HTTP请求,Xdebug从HTTP头中检测IP地址
  • Xdebug连接到端口9000上检测到的IP(10.0.1.42)
  • 调试运行,提供HTTP响应

流程

7c8bad15595a7ed97230e075124cb9ff.png | center | 827x436

1. 安装xdebug扩展

https://xdebug.org/download.php

2. 远程环境配置

zend_extension=xdebug.so
xdebug.idekey=PHPSTORM
xdebug.remote_connect_back = 1
//如果开启此,将忽略下面的 xdebug.remote_host 的参数

xdebug.remote_host=192.168.x.x
//注意这里是,客户端的ip<即IDE的机器的ip,不是你的web server>

xdebug.remote_enable=on
xdebug.remote_port = 9001
//注意这里是,客户端的端口<即IDE的机器的ip,不是你的web server>

xdebug.remote_handler = dbgp
xdebug.auto_trace = 1
xdebug.remote_log = /tmp/xdebug.log

3. 配置deployment

v2-169647ab9bc2bf755f572ef4b0ff4116_hd.jpg | center | 720x641

4. Phpstorm Debug配置

企业微信截图_153663027822.png | center | 827x571

5. 开启phpstorm 数据监听

企业微信截图_15366307559249.png | center | 446x79

6. 设置 debug session

debug session 的工具的目的是设置一个cookie, 让每次发送数据的时候都会携带这个 cookie, 从而识别监听.

6.1) 安装工具
https://chrome.google.com/webstore/detail/xdebug-helper/eadndfjplgieldjbigjakmdgkmoaaaoc

6.2) 点击图标设置

企业微信截图_15366310693718.png | center | 202x226

6.3) 已经设置了cookie, Key 是 XDEBUG_SESSION, 值是 PHPSTORM

企业微信截图_153663027822.png | center | 824x446

7. 运行页面

企业微信截图_15365753413668.png | center | 622x234

其他调试方式

上面的模式有个缺点,插件是针对于一个标签页
快捷键:
Mac: Ctrl+Shift+X Windows:Alt+Shift+X

内部模式

1. 设置 web 访问的服务器

企业微信截图_15366324012641.png | center | 827x571

2. 配置调试页面

我们这里创建的调试页面的类型是PHP Web Page, 服务器选择的是刚才已经建立好的服务器

企业微信截图_15366324012641.png | center | 827x554

3. 运行测试页面

企业微信截图_15366324012641.png | center | 287x97

自动生成:XDEBUG_SESSION_START
http://example.com/?XDEBUG_SESSION_START=13608

Fiddler工具调试

if (oSession.host == "xxxx")
{
    var sCookie = oSession.oRequest["Cookie"] + ';XDEBUG_SESSION=PHPSTORM;';
    oSession.oRequest.headers.Add("Cookie", sCookie);        
}

命令行

export XDEBUG_CONFIG="idekey=PHPSTORM"
php myscript.php

多人开发模式

https://derickrethans.nl/debugging-with-multiple-users.html
插件下载地址:http://code.activestate.com/komodo/remotedebugging/

其他

1. 查看兼容性

第一次运行的时候可以通过 phpstorm 自带的工具来检查配置的兼容性.
Run > Web Server Debug Validation
校验代码
https://gist.github.com/han8g...

2. debug 帮助面板说明

2cd9bf236c0d2ef6f143943fe82c240a.png | center | 827x201

左侧
绿色三角形 : Resume Program,表示將继续执行,直到下一个中断点停止。
红色方形 : Stop,表示中断当前程序调试。

上方
第一个图形示 : Step Over,跳过当前函数。
第二个图形示 : Step Into,进入当前函数內部的程序(相当于观察程序一步一步执行)。
第三个图形示 : Force Step Into,強制进入当前函数內部的程序。
第四个图形示 : Step Out,跳出当前函数內部的程式。
第五个图形示 : Run to Cursor,定位到当前光标。

参考文章

https://segmentfault.com/a/1190000011387666

查看原文

牙小木木 赞了文章 · 2020-12-23

使用Xdebug进行远程调试

为什么要用?

  1. 方便联调:
    和客户端一起联调,是die(); exit(); 会影响其他人员是使用。
  2. 关注数据变化:
    正常情况下,我们在调试和开发时,更关注数据的变化。频繁断点、效率比较低。
  3. 简单:
    之前的开发自己比较懒,一直没用,用起来发现很简单。

原理

运行xdebug需要客户端IDE(phpstorm)、远程服务器配合,首先是客户端配置好端口,发送debug请求,请求会通过浏览器或者IDE的http请求,携带特定的参数发送到服务端,服务端收到请求后,发现这是一个xdebug请求,则与IDE建立dpgp连接,当遇到断点时候,返回调试信息给IDE

image | left

  • 服务器的IP是10.0.1.2,端口80上有HTTP
  • IDE位于未知IP上,因此xdebug.remote_connect_back设置为1
  • IDE侦听端口9000,因此xdebug.remote_port设置为9000
  • 发出HTTP请求,Xdebug从HTTP头中检测IP地址
  • Xdebug连接到端口9000上检测到的IP(10.0.1.42)
  • 调试运行,提供HTTP响应

流程

7c8bad15595a7ed97230e075124cb9ff.png | center | 827x436

1. 安装xdebug扩展

https://xdebug.org/download.php

2. 远程环境配置

zend_extension=xdebug.so
xdebug.idekey=PHPSTORM
xdebug.remote_connect_back = 1
//如果开启此,将忽略下面的 xdebug.remote_host 的参数

xdebug.remote_host=192.168.x.x
//注意这里是,客户端的ip<即IDE的机器的ip,不是你的web server>

xdebug.remote_enable=on
xdebug.remote_port = 9001
//注意这里是,客户端的端口<即IDE的机器的ip,不是你的web server>

xdebug.remote_handler = dbgp
xdebug.auto_trace = 1
xdebug.remote_log = /tmp/xdebug.log

3. 配置deployment

v2-169647ab9bc2bf755f572ef4b0ff4116_hd.jpg | center | 720x641

4. Phpstorm Debug配置

企业微信截图_153663027822.png | center | 827x571

5. 开启phpstorm 数据监听

企业微信截图_15366307559249.png | center | 446x79

6. 设置 debug session

debug session 的工具的目的是设置一个cookie, 让每次发送数据的时候都会携带这个 cookie, 从而识别监听.

6.1) 安装工具
https://chrome.google.com/webstore/detail/xdebug-helper/eadndfjplgieldjbigjakmdgkmoaaaoc

6.2) 点击图标设置

企业微信截图_15366310693718.png | center | 202x226

6.3) 已经设置了cookie, Key 是 XDEBUG_SESSION, 值是 PHPSTORM

企业微信截图_153663027822.png | center | 824x446

7. 运行页面

企业微信截图_15365753413668.png | center | 622x234

其他调试方式

上面的模式有个缺点,插件是针对于一个标签页
快捷键:
Mac: Ctrl+Shift+X Windows:Alt+Shift+X

内部模式

1. 设置 web 访问的服务器

企业微信截图_15366324012641.png | center | 827x571

2. 配置调试页面

我们这里创建的调试页面的类型是PHP Web Page, 服务器选择的是刚才已经建立好的服务器

企业微信截图_15366324012641.png | center | 827x554

3. 运行测试页面

企业微信截图_15366324012641.png | center | 287x97

自动生成:XDEBUG_SESSION_START
http://example.com/?XDEBUG_SESSION_START=13608

Fiddler工具调试

if (oSession.host == "xxxx")
{
    var sCookie = oSession.oRequest["Cookie"] + ';XDEBUG_SESSION=PHPSTORM;';
    oSession.oRequest.headers.Add("Cookie", sCookie);        
}

命令行

export XDEBUG_CONFIG="idekey=PHPSTORM"
php myscript.php

多人开发模式

https://derickrethans.nl/debugging-with-multiple-users.html
插件下载地址:http://code.activestate.com/komodo/remotedebugging/

其他

1. 查看兼容性

第一次运行的时候可以通过 phpstorm 自带的工具来检查配置的兼容性.
Run > Web Server Debug Validation
校验代码
https://gist.github.com/han8g...

2. debug 帮助面板说明

2cd9bf236c0d2ef6f143943fe82c240a.png | center | 827x201

左侧
绿色三角形 : Resume Program,表示將继续执行,直到下一个中断点停止。
红色方形 : Stop,表示中断当前程序调试。

上方
第一个图形示 : Step Over,跳过当前函数。
第二个图形示 : Step Into,进入当前函数內部的程序(相当于观察程序一步一步执行)。
第三个图形示 : Force Step Into,強制进入当前函数內部的程序。
第四个图形示 : Step Out,跳出当前函数內部的程式。
第五个图形示 : Run to Cursor,定位到当前光标。

参考文章

https://segmentfault.com/a/1190000011387666

查看原文

赞 6 收藏 6 评论 0

牙小木木 关注了专栏 · 2020-11-30

纸上得来终觉浅

学会舍弃,活在当下。

关注 1

牙小木木 发布了文章 · 2020-10-10

mac上安装virtualbox并设置共享

关闭声音,关闭声音,关闭声音

image.png
默认这里是打开的,就是因为这个原因导致总是启动后无缘无故的crash。后来被逼无奈,装了vmware。但是vmware又把脆弱的mac的风扇刚刚响。后来忍受不了,上油管看到了视频下的评论。真是太赞了

rc=-1908

(reboot)打开系统偏好设置 -> 安全性与隐私,下方有个允许Oracle ...的请求,点击允许之后再次启动虚拟机就可以了

安装tools

sudo apt-get install virtualbox-guest-utils

设置固定挂载

image.png

执行

mount -t vboxsf code /mnt/code

可以愉快的玩耍了^_^

查看原文

赞 0 收藏 0 评论 0

牙小木木 发布了文章 · 2020-09-30

mac 上安装VMwareTools

  1. 安装破解vmware 略过
  2. 设置CD/DVD为自动检测(如下图)
  3. image.png
  4. 自定义共享文件(如下图)
  5. image.png
  6. ubuntu server中 挂载安装tools
    # 创建media目录
   19  mkdir -p /media/cdrom
    # 讲cd 挂载到上面目录
   20  mount /dev/cdrom /media/cdrom
   21  cd /media/cdrom/
   22  ls
    # 复制
   23  cp VMwareTools-10.3.2-9925305.tar.gz  /home/
   24  cd /home/
   25  tar zxvf VMwareTools-10.3.2-9925305.tar.gz
   26  cd vmware-tools-distrib/
    # -d代表默认安装
   27  ./vmware-install.pl -d
   
         ...
        Creating a new initrd boot image for the kernel.
        update-initramfs: Generating /boot/initrd.img-4.15.0-118-generic
        The configuration of VMware Tools 10.3.2 build-9925305 for Linux for this
        running kernel completed successfully.

        Enjoy,

        --the VMware team

    # 出现上面enjoy代表成功
   34  cd vmware-tools-distrib/
   35  ls
   36  ./bin/vmware-config-tools.pl
   37  ls
   38  cd installer/
   39  ls
   40  ./services.sh
   41  ./services.sh  start 
  1. 执行应该看到和上面第二个图的文件夹回显
 root@tb:/home/vmware-tools-distrib/bin# /usr/bin/vmware-hgfsclient
    DiProject
    MacUbuntuBridge

7.经过一番路径(暴力)查找 ,就可以顺利的共享文件了

   68  find / -name  MacUbuntuBridge
   69  cd /mnt/hgfs/MacUbuntuBridge/
  1. 宿主机和虚拟机对比。ok
root@tb:/mnt/hgfs/MacUbuntuBridge# ls
111.md  222.md  xiaojudeng.thrift
root@tb:/mnt/hgfs/MacUbuntuBridge#

image.png

查看原文

赞 0 收藏 0 评论 0

牙小木木 发布了文章 · 2020-09-17

mysql Explain初探

mysql执行计划

​ 在企业的应用场景中,为了知道优化SQL语句的执行,需要查看SQL语句的具体执行过程,以加快SQL语句的执行效率。

​ 可以使用explain+SQL语句来模拟优化器执行SQL查询语句,从而知道mysql是如何处理sql语句的。

​ 官网地址: https://dev.mysql.com/doc/ref...

1、执行计划中包含的信息

ColumnMeaning
idThe SELECT identifier
select_typeThe SELECT type
tableThe table for the output row
partitionsThe matching partitions
typeThe join type
possible_keysThe possible indexes to choose
keyThe index actually chosen
key_lenThe length of the chosen key
refThe columns compared to the index
rowsEstimate of rows to be examined
filteredPercentage of rows filtered by table condition
extraAdditional information

id

select查询的序列号,包含一组数字,表示查询中执行select子句或者操作表的顺序

id号分为三种情况:

​ 1、如果id相同,那么执行顺序从上到下

explain select * from emp e join dept d on e.deptno = d.deptno join salgrade sg on e.sal between sg.losal and sg.hisal;

​ 2、如果id不同,如果是子查询,id的序号会递增,id值越大优先级越高,越先被执行

explain select * from emp e where e.deptno in (select d.deptno from dept d where d.dname = 'SALES');

​ 3、id相同和不同的,同时存在:相同的可以认为是一组,从上往下顺序执行,在所有组中,id值越大,优先级越高,越先执行

explain select * from emp e join dept d on e.deptno = d.deptno join salgrade sg on e.sal between sg.losal and sg.hisal where e.deptno in (select d.deptno from dept d where d.dname = 'SALES');

select_type

主要用来分辨查询的类型,是普通查询还是联合查询还是子查询

select_type ValueMeaning
SIMPLESimple SELECT (not using UNION or subqueries)
PRIMARYOutermost SELECT
UNIONSecond or later SELECT statement in a UNION
DEPENDENT UNIONSecond or later SELECT statement in a UNION, dependent on outer query
UNION RESULTResult of a UNION.
SUBQUERYFirst SELECT in subquery
DEPENDENT SUBQUERYFirst SELECT in subquery, dependent on outer query
DERIVEDDerived table
UNCACHEABLE SUBQUERYA subquery for which the result cannot be cached and must be re-evaluated for each row of the outer query
UNCACHEABLE UNIONThe second or later select in a UNION that belongs to an uncacheable subquery (see UNCACHEABLE SUBQUERY)
--sample:简单的查询,不包含子查询和union
explain select * from emp;

--primary:查询中若包含任何复杂的子查询,最外层查询则被标记为Primary
explain select staname,ename supname from (select ename staname,mgr from emp) t join emp on t.mgr=emp.empno ;

--union:若第二个select出现在union之后,则被标记为union
explain select * from emp where deptno = 10 union select * from emp where sal >2000;

--dependent union:跟union类似,此处的depentent表示union或union all联合而成的结果会受外部表影响
explain select * from emp e where e.empno  in ( select empno from emp where deptno = 10 union select empno from emp where sal >2000)

--union result:从union表获取结果的select
explain select * from emp where deptno = 10 union select * from emp where sal >2000;

--subquery:在select或者where列表中包含子查询
explain select * from emp where sal > (select avg(sal) from emp) ;

--dependent subquery:subquery的子查询要受到外部表查询的影响
explain select * from emp e where e.deptno in (select distinct deptno from dept);

--DERIVED: from子句中出现的子查询,也叫做派生类,
explain select staname,ename supname from (select ename staname,mgr from emp) t join emp on t.mgr=emp.empno ;

--UNCACHEABLE SUBQUERY:表示使用子查询的结果不能被缓存
 explain select * from emp where empno = (select empno from emp where deptno=@@sort_buffer_size);
 
--uncacheable union:表示union的查询结果不能被缓存:sql语句未验证

table

对应行正在访问哪一个表,表名或者别名,可能是临时表或者union合并结果集

    1、如果是具体的表名,则表明从实际的物理表中获取数据,当然也可以是表的别名

​ 2、表名是derivedN的形式,表示使用了id为N的查询产生的衍生表

​ 3、当有union result的时候,表名是union n1,n2等的形式,n1,n2表示参与union的id

type

type显示的是访问类型,访问类型表示我是以何种方式去访问我们的数据,最容易想的是全表扫描,直接暴力的遍历一张表去寻找需要的数据,效率非常低下,访问的类型有很多,效率从最好到最坏依次是:

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL

一般情况下,得保证查询至少达到range级别,最好能达到ref

--all:全表扫描,一般情况下出现这样的sql语句而且数据量比较大的话那么就需要进行优化。
explain select * from emp;

--index:全索引扫描这个比all的效率要好,主要有两种情况,一种是当前的查询时覆盖索引,即我们需要的数据在索引中就可以索取,或者是使用了索引进行排序,这样就避免数据的重排序
explain  select empno from emp;

--range:表示利用索引查询的时候限制了范围,在指定范围内进行查询,这样避免了index的全索引扫描,适用的操作符: =, <>, >, >=, <, <=, IS NULL, BETWEEN, LIKE, or IN() 
explain select * from emp where empno between 7000 and 7500;

--index_subquery:利用索引来关联子查询,不再扫描全表
explain select * from emp where emp.job in (select job from t_job);

--unique_subquery:该连接类型类似与index_subquery,使用的是唯一索引
 explain select * from emp e where e.deptno in (select distinct deptno from dept);
 
--index_merge:在查询过程中需要多个索引组合使用,没有模拟出来

--ref_or_null:对于某个字段即需要关联条件,也需要null值的情况下,查询优化器会选择这种访问方式
explain select * from emp e where  e.mgr is null or e.mgr=7369;

--ref:使用了非唯一性索引进行数据的查找
 create index idx_3 on emp(deptno);
 explain select * from emp e,dept d where e.deptno =d.deptno;

--eq_ref :使用唯一性索引进行数据查找
explain select * from emp,emp2 where emp.empno = emp2.empno;

--const:这个表至多有一个匹配行,
explain select * from emp where empno = 7369;
 
--system:表只有一行记录(等于系统表),这是const类型的特例,平时不会出现

possible_keys

​ 显示可能应用在这张表中的索引,一个或多个,查询涉及到的字段上若存在索引,则该索引将被列出,但不一定被查询实际使用

explain select * from emp,dept where emp.deptno = dept.deptno and emp.deptno = 10;

key

​ 实际使用的索引,如果为null,则没有使用索引,查询中若使用了覆盖索引,则该索引和查询的select字段重叠。

explain select * from emp,dept where emp.deptno = dept.deptno and emp.deptno = 10;

key_len

表示索引中使用的字节数,可以通过key_len计算查询中使用的索引长度,在不损失精度的情况下长度越短越好。

explain select * from emp,dept where emp.deptno = dept.deptno and emp.deptno = 10;

ref

显示索引的哪一列被使用了,如果可能的话,是一个常数

explain select * from emp,dept where emp.deptno = dept.deptno and emp.deptno = 10;

rows

根据表的统计信息及索引使用情况,大致估算出找出所需记录需要读取的行数,此参数很重要,直接反应的sql找了多少数据,在完成目的的情况下越少越好

explain select * from emp;

extra

包含额外的信息。

--using filesort:说明mysql无法利用索引进行排序,只能利用排序算法进行排序,会消耗额外的位置
explain select * from emp order by sal;

--using temporary:建立临时表来保存中间结果,查询完成之后把临时表删除
explain select ename,count(*) from emp where deptno = 10 group by ename;

--using index:这个表示当前的查询时覆盖索引的,直接从索引中读取数据,而不用访问数据表。如果同时出现using where 表名索引被用来执行索引键值的查找,如果没有,表面索引被用来读取数据,而不是真的查找
explain select deptno,count(*) from emp group by deptno limit 10;

--using where:使用where进行条件过滤
explain select * from t_user where id = 1;

--using join buffer:使用连接缓存,情况没有模拟出来

--impossible where:where语句的结果总是false
explain select * from emp where empno = 7469;

Thanks 马士兵教育

查看原文

赞 0 收藏 0 评论 0

认证与成就

  • 获得 220 次点赞
  • 获得 39 枚徽章 获得 1 枚金徽章, 获得 9 枚银徽章, 获得 29 枚铜徽章

擅长技能
编辑

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2015-07-29
个人主页被 2.7k 人浏览