在路上

在路上 查看完整档案

北京编辑东北石油大学  |  电子信息科学与技术 编辑  |  填写所在公司/组织 www.jianshu.com/u/cca8a33b7ffa 编辑
编辑
_ | |__ _ _ __ _ | '_ \| | | |/ _` | | |_) | |_| | (_| | |_.__/ \__,_|\__, | |___/ 该用户太懒什么也没留下

个人动态

在路上 发布了文章 · 2018-08-28

使用Guava RateLimiter限流以及源码解析

前言

在开发高并发系统时有三把利器用来保护系统:缓存、降级和限流

  • 缓存 缓存的目的是提升系统访问速度和增大系统处理容量
  • 降级 降级是当服务出现问题或者影响到核心流程时,需要暂时屏蔽掉,待高峰或者问题解决后再打开
  • 限流 限流的目的是通过对并发访问/请求进行限速,或者对一个时间窗口内的请求进行限速来保护系统,一旦达到限制速率则可以拒绝服务、排队或等待、降级等处理

常用的限流算法

漏桶算法

漏桶算法思路很简单,水(请求)先进入到漏桶里,漏桶以一定的速度出水,当水流入速度过大会直接溢出,可以看出漏桶算法能强行限制数据的传输速率。

img

令牌桶算法

对于很多应用场景来说,除了要求能够限制数据的平均传输速率外,还要求允许某种程度的突发传输。这时候漏桶算法可能就不合适了,令牌桶算法更为适合。如图所示,令牌桶算法的原理是系统会以一个恒定的速度往桶里放入令牌,而如果请求需要被处理,则需要先从桶里获取一个令牌,当桶里没有令牌可取时,则拒绝服务。

img

RateLimiter使用以及源码解析

Google开源工具包Guava提供了限流工具类RateLimiter,该类基于令牌桶算法实现流量限制,使用十分方便,而且十分高效。

RateLimiter使用

首先简单介绍下RateLimiter的使用,

public void testAcquire() {
      RateLimiter limiter = RateLimiter.create(1);

      for(int i = 1; i < 10; i = i + 2 ) {
          double waitTime = limiter.acquire(i);
          System.out.println("cutTime=" + System.currentTimeMillis() + " acq:" + i + " waitTime:" + waitTime);
      }
  }

输出结果:

cutTime=1535439657427 acq:1 waitTime:0.0
cutTime=1535439658431 acq:3 waitTime:0.997045
cutTime=1535439661429 acq:5 waitTime:2.993028
cutTime=1535439666426 acq:7 waitTime:4.995625
cutTime=1535439673426 acq:9 waitTime:6.999223

首先通过RateLimiter.create(1);创建一个限流器,参数代表每秒生成的令牌数,通过limiter.acquire(i);来以阻塞的方式获取令牌,当然也可以通过tryAcquire(int permits, long timeout, TimeUnit unit)来设置等待超时时间的方式获取令牌,如果超timeout为0,则代表非阻塞,获取不到立即返回。

从输出来看,RateLimiter支持预消费,比如在acquire(5)时,等待时间是3秒,是上一个获取令牌时预消费了3个两排,固需要等待3*1秒,然后又预消费了5个令牌,以此类推

RateLimiter通过限制后面请求的等待时间,来支持一定程度的突发请求(预消费),在使用过程中需要注意这一点,具体实现原理后面再分析。

RateLimiter实现原理

Guava有两种限流模式,一种为稳定模式(SmoothBursty:令牌生成速度恒定),一种为渐进模式(SmoothWarmingUp:令牌生成速度缓慢提升直到维持在一个稳定值) 两种模式实现思路类似,主要区别在等待时间的计算上,本篇重点介绍SmoothBursty
RateLimiter的创建

通过调用RateLimiter的create接口来创建实例,实际是调用的SmoothBuisty稳定模式创建的实例。

public static RateLimiter create(double permitsPerSecond) {
    return create(permitsPerSecond, SleepingStopwatch.createFromSystemTimer());
  }

  static RateLimiter create(double permitsPerSecond, SleepingStopwatch stopwatch) {
    RateLimiter rateLimiter = new SmoothBursty(stopwatch, 1.0 /* maxBurstSeconds */);
    rateLimiter.setRate(permitsPerSecond);
    return rateLimiter;
  }

SmoothBursty中的两个构造参数含义:

  • SleepingStopwatch:guava中的一个时钟类实例,会通过这个来计算时间及令牌
  • maxBurstSeconds:官方解释,在ReteLimiter未使用时,最多保存几秒的令牌,默认是1

在解析SmoothBursty原理前,重点解释下SmoothBursty中几个属性的含义

/**
 * The work (permits) of how many seconds can be saved up if this RateLimiter is unused?
 * 在RateLimiter未使用时,最多存储几秒的令牌
 * */
 final double maxBurstSeconds;
 

/**
 * The currently stored permits.
 * 当前存储令牌数
 */
double storedPermits;

/**
 * The maximum number of stored permits.
 * 最大存储令牌数 = maxBurstSeconds * stableIntervalMicros(见下文)
 */
double maxPermits;

/**
 * The interval between two unit requests, at our stable rate. E.g., a stable rate of 5 permits
 * per second has a stable interval of 200ms.
 * 添加令牌时间间隔 = SECONDS.toMicros(1L) / permitsPerSecond;(1秒/每秒的令牌数)
 */
double stableIntervalMicros;

/**
 * The time when the next request (no matter its size) will be granted. After granting a request,
 * this is pushed further in the future. Large requests push this further than small requests.
 * 下一次请求可以获取令牌的起始时间
 * 由于RateLimiter允许预消费,上次请求预消费令牌后
 * 下次请求需要等待相应的时间到nextFreeTicketMicros时刻才可以获取令牌
 */
private long nextFreeTicketMicros = 0L; // could be either in the past or future

接下来介绍几个关键函数

  • setRate
public final void setRate(double permitsPerSecond) {
  checkArgument(
      permitsPerSecond > 0.0 && !Double.isNaN(permitsPerSecond), "rate must be positive");
  synchronized (mutex()) {
    doSetRate(permitsPerSecond, stopwatch.readMicros());
  }
}

通过这个接口设置令牌通每秒生成令牌的数量,内部时间通过调用SmoothRateLimiterdoSetRate来实现

  • doSetRate
@Override
  final void doSetRate(double permitsPerSecond, long nowMicros) {
    resync(nowMicros);
    double stableIntervalMicros = SECONDS.toMicros(1L) / permitsPerSecond;
    this.stableIntervalMicros = stableIntervalMicros;
    doSetRate(permitsPerSecond, stableIntervalMicros);
  }

这里先通过调用resync生成令牌以及更新下一期令牌生成时间,然后更新stableIntervalMicros,最后又调用了SmoothBurstydoSetRate

  • resync
/**
 * Updates {@code storedPermits} and {@code nextFreeTicketMicros} based on the current time.
 * 基于当前时间,更新下一次请求令牌的时间,以及当前存储的令牌(可以理解为生成令牌)
 */
void resync(long nowMicros) {
    // if nextFreeTicket is in the past, resync to now
    if (nowMicros > nextFreeTicketMicros) {
      double newPermits = (nowMicros - nextFreeTicketMicros) / coolDownIntervalMicros();
      storedPermits = min(maxPermits, storedPermits + newPermits);
      nextFreeTicketMicros = nowMicros;
    }
}

根据令牌桶算法,桶中的令牌是持续生成存放的,有请求时需要先从桶中拿到令牌才能开始执行,谁来持续生成令牌存放呢?

一种解法是,开启一个定时任务,由定时任务持续生成令牌。这样的问题在于会极大的消耗系统资源,如,某接口需要分别对每个用户做访问频率限制,假设系统中存在6W用户,则至多需要开启6W个定时任务来维持每个桶中的令牌数,这样的开销是巨大的。

另一种解法则是延迟计算,如上resync函数。该函数会在每次获取令牌之前调用,其实现思路为,若当前时间晚于nextFreeTicketMicros,则计算该段时间内可以生成多少令牌,将生成的令牌加入令牌桶中并更新数据。这样一来,只需要在获取令牌时计算一次即可。

  • SmoothBursty的doSetRate
@Override
void doSetRate(double permitsPerSecond, double stableIntervalMicros) {
  double oldMaxPermits = this.maxPermits;
  maxPermits = maxBurstSeconds * permitsPerSecond;
  if (oldMaxPermits == Double.POSITIVE_INFINITY) {
    // if we don't special-case this, we would get storedPermits == NaN, below
    // Double.POSITIVE_INFINITY 代表无穷啊
    storedPermits = maxPermits;
  } else {
    storedPermits =
        (oldMaxPermits == 0.0)
            ? 0.0 // initial state
            : storedPermits * maxPermits / oldMaxPermits;
  }
}

桶中可存放的最大令牌数由maxBurstSeconds计算而来,其含义为最大存储maxBurstSeconds秒生成的令牌。
该参数的作用在于,可以更为灵活地控制流量。如,某些接口限制为300次/20秒,某些接口限制为50次/45秒等。也就是流量不局限于qps

RateLimiter几个常用接口分析

在了解以上概念后,就非常容易理解RateLimiter暴露出来的接口

@CanIgnoreReturnValue
public double acquire() {
  return acquire(1);
}

/**
* 获取令牌,返回阻塞的时间
**/
@CanIgnoreReturnValue
public double acquire(int permits) {
  long microsToWait = reserve(permits);
  stopwatch.sleepMicrosUninterruptibly(microsToWait);
  return 1.0 * microsToWait / SECONDS.toMicros(1L);
}

final long reserve(int permits) {
  checkPermits(permits);
  synchronized (mutex()) {
    return reserveAndGetWaitLength(permits, stopwatch.readMicros());
  }
}

acquire函数主要用于获取permits个令牌,并计算需要等待多长时间,进而挂起等待,并将该值返回,主要通过reserve返回需要等待的时间,reserve中通过调用reserveAndGetWaitLength获取等待时间

/**
 * Reserves next ticket and returns the wait time that the caller must wait for.
 *
 * @return the required wait time, never negative
 */
final long reserveAndGetWaitLength(int permits, long nowMicros) {
  long momentAvailable = reserveEarliestAvailable(permits, nowMicros);
  return max(momentAvailable - nowMicros, 0);
}

最后调用了reserveEarliestAvailable

@Override
final long reserveEarliestAvailable(int requiredPermits, long nowMicros) {
  resync(nowMicros);
  long returnValue = nextFreeTicketMicros;
  double storedPermitsToSpend = min(requiredPermits, this.storedPermits);
  double freshPermits = requiredPermits - storedPermitsToSpend;
  long waitMicros =
      storedPermitsToWaitTime(this.storedPermits, storedPermitsToSpend)
          + (long) (freshPermits * stableIntervalMicros);

  this.nextFreeTicketMicros = LongMath.saturatedAdd(nextFreeTicketMicros, waitMicros);
  this.storedPermits -= storedPermitsToSpend;
  return returnValue;
}
首先通过resync生成令牌以及同步nextFreeTicketMicros时间戳,freshPermits从令牌桶中获取令牌后还需要的令牌数量,通过storedPermitsToWaitTime计算出获取freshPermits还需要等待的时间,在稳定模式中,这里就是(long) (freshPermits * stableIntervalMicros) ,然后更新nextFreeTicketMicros以及storedPermits,这次获取令牌需要的等待到的时间点, reserveAndGetWaitLength返回需要等待的时间间隔。

从`reserveEarliestAvailable`可以看出RateLimiter的预消费原理,以及获取令牌的等待时间时间原理(可以解释示例结果),再获取令牌不足时,并没有等待到令牌全部生成,而是更新了下次获取令牌时的nextFreeTicketMicros,从而影响的是下次获取令牌的等待时间。



 `reserve`这里返回等待时间后,`acquire`通过调用`stopwatch.sleepMicrosUninterruptibly(microsToWait);`进行sleep操作,这里不同于Thread.sleep(), 这个函数的sleep是uninterruptibly的,内部实现:
public static void sleepUninterruptibly(long sleepFor, TimeUnit unit) {
    //sleep 阻塞线程 内部通过Thread.sleep()
  boolean interrupted = false;
  try {
    long remainingNanos = unit.toNanos(sleepFor);
    long end = System.nanoTime() + remainingNanos;
    while (true) {
      try {
        // TimeUnit.sleep() treats negative timeouts just like zero.
        NANOSECONDS.sleep(remainingNanos);
        return;
      } catch (InterruptedException e) {
        interrupted = true;
        remainingNanos = end - System.nanoTime();
        //如果被interrupt可以继续,更新sleep时间,循环继续sleep
      }
    }
  } finally {
    if (interrupted) {
      Thread.currentThread().interrupt();
      //如果被打断过,sleep过后再真正中断线程
    }
  }
}
 sleep之后,`acquire`返回sleep的时间,阻塞结束,获取到令牌。



public boolean tryAcquire(int permits) {
  return tryAcquire(permits, 0, MICROSECONDS);
}

public boolean tryAcquire() {
  return tryAcquire(1, 0, MICROSECONDS);
}

public boolean tryAcquire(int permits, long timeout, TimeUnit unit) {
  long timeoutMicros = max(unit.toMicros(timeout), 0);
  checkPermits(permits);
  long microsToWait;
  synchronized (mutex()) {
    long nowMicros = stopwatch.readMicros();
    if (!canAcquire(nowMicros, timeoutMicros)) {
      return false;
    } else {
      microsToWait = reserveAndGetWaitLength(permits, nowMicros);
    }
  }
  stopwatch.sleepMicrosUninterruptibly(microsToWait);
  return true;
}

private boolean canAcquire(long nowMicros, long timeoutMicros) {
  return queryEarliestAvailable(nowMicros) - timeoutMicros <= nowMicros;
}

@Override
final long queryEarliestAvailable(long nowMicros) {
  return nextFreeTicketMicros;
}

tryAcquire函数可以尝试在timeout时间内获取令牌,如果可以则挂起等待相应时间并返回true,否则立即返回false
canAcquire用于判断timeout时间内是否可以获取令牌,通过判断当前时间+超时时间是否大于nextFreeTicketMicros 来决定是否能够拿到足够的令牌数,如果可以获取到,则过程同acquire,线程sleep等待,如果通过canAcquire在此超时时间内不能回去到令牌,则可以快速返回,不需要等待timeout后才知道能否获取到令牌。

因为SmoothBursty允许一定程度的突发,会有人担心如果允许这种突发,假设突然间来了很大的流量,那么系统很可能扛不住这种突发。因此需要一种平滑速率的限流工具,从而系统冷启动后慢慢的趋于平均固定速率(即刚开始速率小一些,然后慢慢趋于我们设置的固定速率)。Guava也提供了SmoothWarmingUp来实现这种需求,其可以认为是漏桶算法,但是在某些特殊场景又不太一样。

SmoothWarmingUp创建方式:

public static RateLimiter create(double permitsPerSecond, long warmupPeriod, TimeUnit unit) {
  checkArgument(warmupPeriod >= 0, "warmupPeriod must not be negative: %s", warmupPeriod);
  return create(
      permitsPerSecond, warmupPeriod, unit, 3.0, SleepingStopwatch.createFromSystemTimer());
}

permitsPerSecond表示每秒新增的令牌数,warmupPeriod表示在从冷启动速率过渡到平均速率的时间间隔,大致原理是类似的,这里就先不分析了。

到此,Guava RateLimiter稳定模式的实现原理基本已经清楚,如发现文中错误的地方,劳烦指正!

上述分析主要参考了:https://segmentfault.com/a/11...,再此基础上做了些笔记补充

查看原文

赞 2 收藏 2 评论 1

在路上 赞了文章 · 2017-12-15

面试官最爱的volatile关键字

在Java相关的岗位面试中,很多面试官都喜欢考察面试者对Java并发的了解程度,而以volatile关键字作为一个小的切入点,往往可以一问到底,把Java内存模型(JMM),Java并发编程的一些特性都牵扯出来,深入地话还可以考察JVM底层实现以及操作系统的相关知识。
下面我们以一次假想的面试过程,来深入了解下volitile关键字吧!

面试官: Java并发这块了解的怎么样?说说你对volatile关键字的理解

就我理解的而言,被volatile修饰的共享变量,就具有了以下两点特性:

  • 1.保证了不同线程对该变量操作的内存可见性;
  • 2.禁止指令重排序

面试官: 能不能详细说下什么是内存可见性,什么又是重排序呢?

这个聊起来可就多了,我还是从Java内存模型说起吧。
Java虚拟机规范试图定义一种Java内存模型(JMM),来屏蔽掉各种硬件和操作系统的内存访问差异,让Java程序在各种平台上都能达到一致的内存访问效果。简单来说,由于CPU执行指令的速度是很快的,但是内存访问的速度就慢了很多,相差的不是一个数量级,所以搞处理器的那群大佬们又在CPU里加了好几层高速缓存。
在Java内存模型里,对上述的优化又进行了一波抽象。JMM规定所有变量都是存在主存中的,类似于上面提到的普通内存,每个线程又包含自己的工作内存,方便理解就可以看成CPU上的寄存器或者高速缓存。所以线程的操作都是以工作内存为主,它们只能访问自己的工作内存,且工作前后都要把值在同步回主内存。
这么说得我自己都有些不清楚了,拿张纸画一下:

JMM

在线程执行时,首先会从主存中read变量值,再load到工作内存中的副本中,然后再传给处理器执行,执行完毕后再给工作内存中的副本赋值,随后工作内存再把值传回给主存,主存中的值才更新。

使用工作内存和主存,虽然加快的速度,但是也带来了一些问题。比如看下面一个例子:

i = i + 1;

假设i初值为0,当只有一个线程执行它时,结果肯定得到1,当两个线程执行时,会得到结果2吗?这倒不一定了。可能存在这种情况:

线程1: load i from 主存    // i = 0
        i + 1  // i = 1
线程2: load i from主存  // 因为线程1还没将i的值写回主存,所以i还是0
        i +  1 //i = 1
线程1:  save i to 主存
线程2: save i to 主存

如果两个线程按照上面的执行流程,那么i最后的值居然是1了。如果最后的写回生效的慢,你再读取i的值,都可能是0,这就是缓存不一致问题。

下面就要提到你刚才问到的问题了,JMM主要就是围绕着如何在并发过程中如何处理原子性、可见性和有序性这3个特征来建立的,通过解决这三个问题,可以解除缓存不一致的问题。而volatile跟可见性和有序性都有关。

面试官:那你具体说说这三个特性呢?

1.原子性(Atomicity):

Java中,对基本数据类型的读取和赋值操作是原子性操作,所谓原子性操作就是指这些操作是不可中断的,要做一定做完,要么就没有执行。 比如:

i = 2;
j = i;
i++;
i = i + 1;

上面4个操作中,i=2是读取操作,必定是原子性操作,j=i你以为是原子性操作,其实吧,分为两步,一是读取i的值,然后再赋值给j,这就是2步操作了,称不上原子操作,i++和i = i + 1其实是等效的,读取i的值,加1,再写回主存,那就是3步操作了。所以上面的举例中,最后的值可能出现多种情况,就是因为满足不了原子性。

这么说来,只有简单的读取,赋值是原子操作,还只能是用数字赋值,用变量的话还多了一步读取变量值的操作。有个例外是,虚拟机规范中允许对64位数据类型(long和double),分为2次32为的操作来处理,但是最新JDK实现还是实现了原子操作的。

JMM只实现了基本的原子性,像上面i++那样的操作,必须借助于synchronized和Lock来保证整块代码的原子性了。线程在释放锁之前,必然会把i的值刷回到主存的。

2. 可见性(Visibility):

说到可见性,Java就是利用volatile来提供可见性的。
当一个变量被volatile修饰时,那么对它的修改会立刻刷新到主存,当其它线程需要读取该变量时,会去内存中读取新值。而普通变量则不能保证这一点。

其实通过synchronized和Lock也能够保证可见性,线程在释放锁之前,会把共享变量值都刷回主存,但是synchronized和Lock的开销都更大。

3. 有序性(Ordering)

JMM是允许编译器和处理器对指令重排序的,但是规定了as-if-serial语义,即不管怎么重排序,程序的执行结果不能改变。比如下面的程序段:

double pi = 3.14;    //A
double r = 1;        //B
double s= pi * r * r;//C

上面的语句,可以按照A->B->C执行,结果为3.14,但是也可以按照B->A->C的顺序执行,因为A、B是两句独立的语句,而C则依赖于A、B,所以A、B可以重排序,但是C却不能排到A、B的前面。JMM保证了重排序不会影响到单线程的执行,但是在多线程中却容易出问题。

比如这样的代码:

int a = 0;
bool flag = false;

public void write() {
    a = 2;              //1
    flag = true;        //2
}

public void multiply() {
    if (flag) {         //3
        int ret = a * a;//4
    }
}

假如有两个线程执行上述代码段,线程1先执行write,随后线程2再执行multiply,最后ret的值一定是4吗?结果不一定:

JMM

如图所示,write方法里的1和2做了重排序,线程1先对flag赋值为true,随后执行到线程2,ret直接计算出结果,再到线程1,这时候a才赋值为2,很明显迟了一步。

这时候可以为flag加上volatile关键字,禁止重排序,可以确保程序的有序性,也可以上重量级的synchronized和Lock来保证有序性,它们能保证那一块区域里的代码都是一次性执行完毕的。

另外,JMM具备一些先天的有序性,即不需要通过任何手段就可以保证的有序性,通常称为happens-before原则。<<JSR-133:Java Memory Model and Thread Specification>>定义了如下happens-before规则

1.程序顺序规则: 一个线程中的每个操作,happens-before于该线程中的任意后续操作
2.监视器锁规则:对一个线程的解锁,happens-before于随后对这个线程的加锁
3.volatile变量规则: 对一个volatile域的写,happens-before于后续对这个volatile域的读
4.传递性:如果A happens-before B ,且 B happens-before C, 那么 A happens-before C
5.start()规则: 如果线程A执行操作ThreadB_start()(启动线程B) , 那么A线程的ThreadB_start()happens-before 于B中的任意操作
6.join()原则: 如果A执行ThreadB.join()并且成功返回,那么线程B中的任意操作happens-before于线程A从ThreadB.join()操作成功返回。
7.interrupt()原则: 对线程interrupt()方法的调用先行发生于被中断线程代码检测到中断事件的发生,可以通过Thread.interrupted()方法检测是否有中断发生
8.finalize()原则:一个对象的初始化完成先行发生于它的finalize()方法的开始

第1条规则程序顺序规则是说在一个线程里,所有的操作都是按顺序的,但是在JMM里其实只要执行结果一样,是允许重排序的,这边的happens-before强调的重点也是单线程执行结果的正确性,但是无法保证多线程也是如此。

第2条规则监视器规则其实也好理解,就是在加锁之前,确定这个锁之前已经被释放了,才能继续加锁。

第3条规则,就适用到所讨论的volatile,如果一个线程先去写一个变量,另外一个线程再去读,那么写入操作一定在读操作之前。

第4条规则,就是happens-before的传递性。

后面几条就不再一一赘述了。

面试官:volatile关键字如何满足并发编程的三大特性的?

那就要重提volatile变量规则: 对一个volatile域的写,happens-before于后续对这个volatile域的读。
这条再拎出来说,其实就是如果一个变量声明成是volatile的,那么当我读变量时,总是能读到它的最新值,这里最新值是指不管其它哪个线程对该变量做了写操作,都会立刻被更新到主存里,我也能从主存里读到这个刚写入的值。也就是说volatile关键字可以保证可见性以及有序性。

继续拿上面的一段代码举例:

int a = 0;
bool flag = false;

public void write() {
   a = 2;              //1
   flag = true;        //2
}

public void multiply() {
   if (flag) {         //3
       int ret = a * a;//4
   }
}

这段代码不仅仅受到重排序的困扰,即使1、2没有重排序。3也不会那么顺利的执行的。假设还是线程1先执行write操作,线程2再执行multiply操作,由于线程1是在工作内存里把flag赋值为1,不一定立刻写回主存,所以线程2执行时,multiply再从主存读flag值,仍然可能为false,那么括号里的语句将不会执行。

如果改成下面这样:

int a = 0;
volatile bool flag = false;

public void write() {
   a = 2;              //1
   flag = true;        //2
}

public void multiply() {
   if (flag) {         //3
       int ret = a * a;//4
   }
}

那么线程1先执行write,线程2再执行multiply。根据happens-before原则,这个过程会满足以下3类规则:

程序顺序规则:1 happens-before 2; 3 happens-before 4; (volatile限制了指令重排序,所以1 在2 之前执行)
volatile规则:2 happens-before 3
传递性规则:1 happens-before 4

当写一个volatile变量时,JMM会把该线程对应的本地内存中的共享变量刷新到主内存

当读一个volatile变量时,JMM会把该线程对应的本地内存置为无效,线程接下来将从主内存中读取共享变量。

面试官:volatile的两点内存语义能保证可见性和有序性,但是能保证原子性吗?

首先我回答是不能保证原子性,要是说能保证,也只是对单个volatile变量的读/写具有原子性,但是对于类似volatile++这样的复合操作就无能为力了,比如下面的例子:

public class Test {
    public volatile int inc = 0;
 
    public void increase() {
        inc++;
    }
 
    public static void main(String[] args) {
        final Test test = new Test();
        for(int i=0;i<10;i++){
            new Thread(){
                public void run() {
                    for(int j=0;j<1000;j++)
                        test.increase();
                };
            }.start();
        }
 
        while(Thread.activeCount()>1)  //保证前面的线程都执行完
            Thread.yield();
        System.out.println(test.inc);
    }

按道理来说结果是10000,但是运行下很可能是个小于10000的值。有人可能会说volatile不是保证了可见性啊,一个线程对inc的修改,另外一个线程应该立刻看到啊!可是这里的操作inc++是个复合操作啊,包括读取inc的值,对其自增,然后再写回主存。

假设线程A,读取了inc的值为10,这时候被阻塞了,因为没有对变量进行修改,触发不了volatile规则。

线程B此时也读读inc的值,主存里inc的值依旧为10,做自增,然后立刻就被写回主存了,为11。

此时又轮到线程A执行,由于工作内存里保存的是10,所以继续做自增,再写回主存,11又被写了一遍。所以虽然两个线程执行了两次increase(),结果却只加了一次。

有人说,volatile不是会使缓存行无效的吗?但是这里线程A读取到线程B也进行操作之前,并没有修改inc值,所以线程B读取的时候,还是读的10。

又有人说,线程B将11写回主存,不会把线程A的缓存行设为无效吗?但是线程A的读取操作已经做过了啊,只有在做读取操作时,发现自己缓存行无效,才会去读主存的值,所以这里线程A只能继续做自增了。

综上所述,在这种复合操作的情景下,原子性的功能是维持不了了。但是volatile在上面那种设置flag值的例子里,由于对flag的读/写操作都是单步的,所以还是能保证原子性的。

要想保证原子性,只能借助于synchronized,Lock以及并发包下的atomic的原子操作类了,即对基本数据类型的 自增(加1操作),自减(减1操作)、以及加法操作(加一个数),减法操作(减一个数)进行了封装,保证这些操作是原子性操作。

面试官:说的还可以,那你知道volatile底层的实现机制?

如果把加入volatile关键字的代码和未加入volatile关键字的代码都生成汇编代码,会发现加入volatile关键字的代码会多出一个lock前缀指令。

lock前缀指令实际相当于一个内存屏障,内存屏障提供了以下功能:

1.重排序时不能把后面的指令重排序到内存屏障之前的位置
2.使得本CPU的Cache写入内存
3.写入动作也会引起别的CPU或者别的内核无效化其Cache,相当于让新写入的值对别的线程可见。

面试官: 你在哪里会使用到volatile,举两个例子呢?

1.状态量标记,就如上面对flag的标记,我重新提一下:

int a = 0;
volatile bool flag = false;

public void write() {
    a = 2;              //1
    flag = true;        //2
}

public void multiply() {
    if (flag) {         //3
        int ret = a * a;//4
    }
}

这种对变量的读写操作,标记为volatile可以保证修改对线程立刻可见。比synchronized,Lock有一定的效率提升。

2.单例模式的实现,典型的双重检查锁定(DCL)

class Singleton{
    private volatile static Singleton instance = null;
 
    private Singleton() {
 
    }
 
    public static Singleton getInstance() {
        if(instance==null) {
            synchronized (Singleton.class) {
                if(instance==null)
                    instance = new Singleton();
            }
        }
        return instance;
    }
}

这是一种懒汉的单例模式,使用时才创建对象,而且为了避免初始化操作的指令重排序,给instance加上了volatile。

Contact

  • 作者:鹏磊
  • 出处:http://www.ymq.io
  • Email:admin@souyunku.com
  • 版权归作者所有,转载请注明出处
  • Wechat:关注公众号,搜云库,专注于开发技术的研究与知识分享

关注公众号-搜云库

查看原文

赞 21 收藏 67 评论 1

在路上 赞了文章 · 2017-12-11

如果有人问你爬虫抓取技术的门道,请叫他来看这篇文章

本文首发于我的个人博客,同步发布于SegmentFault专栏,非商业转载请注明出处,商业转载请阅读原文链接里的法律声明。

web是一个开放的平台,这也奠定了web从90年代初诞生直至今日将近30年来蓬勃的发展。然而,正所谓成也萧何败也萧何,开放的特性、搜索引擎以及简单易学的html、css技术使得web成为了互联网领域里最为流行和成熟的信息传播媒介;但如今作为商业化软件,web这个平台上的内容信息的版权却毫无保证,因为相比软件客户端而言,你的网页中的内容可以被很低成本、很低的技术门槛实现出的一些抓取程序获取到,这也就是这一系列文章将要探讨的话题—— 网络爬虫

banner

有很多人认为web应当始终遵循开放的精神,呈现在页面中的信息应当毫无保留地分享给整个互联网。然而我认为,在IT行业发展至今天,web已经不再是当年那个和pdf一争高下的所谓 “超文本”信息载体 了,它已经是以一种 轻量级客户端软件 的意识形态的存在了。而商业软件发展到今天,web也不得不面对知识产权保护的问题,试想如果原创的高质量内容得不到保护,抄袭和盗版横行网络世界,这其实对web生态的良性发展是不利的,也很难鼓励更多的优质原创内容的生产。

未授权的爬虫抓取程序是危害web原创内容生态的一大元凶,因此要保护网站的内容,首先就要考虑如何反爬虫。

从爬虫的攻防角度来讲

最简单的爬虫,是几乎所有服务端、客户端编程语言都支持的http请求,只要向目标页面的url发起一个http get请求,即可获得到浏览器加载这个页面时的完整html文档,这被我们称之为“同步页”。

作为防守的一方,服务端可以根据http请求头中的User-Agent来检查客户端是否是一个合法的浏览器程序,亦或是一个脚本编写的抓取程序,从而决定是否将真实的页面信息内容下发给你。

这当然是最小儿科的防御手段,爬虫作为进攻的一方,完全可以伪造User-Agent字段,甚至,只要你愿意,http的get方法里, request header的 ReferrerCookie 等等所有字段爬虫都可以轻而易举的伪造。

此时服务端可以利用浏览器http头指纹,根据你声明的自己的浏览器厂商和版本(来自 User-Agent ),来鉴别你的http header中的各个字段是否符合该浏览器的特征,如不符合则作为爬虫程序对待。这个技术有一个典型的应用,就是 PhantomJS 1.x版本中,由于其底层调用了Qt框架的网络库,因此http头里有明显的Qt框架网络请求的特征,可以被服务端直接识别并拦截。

除此之外,还有一种更加变态的服务端爬虫检测机制,就是对所有访问页面的http请求,在 http response 中种下一个 cookie token ,然后在这个页面内异步执行的一些ajax接口里去校验来访请求是否含有cookie token,将token回传回来则表明这是一个合法的浏览器来访,否则说明刚刚被下发了那个token的用户访问了页面html却没有访问html内执行js后调用的ajax请求,很有可能是一个爬虫程序。

如果你不携带token直接访问一个接口,这也就意味着你没请求过html页面直接向本应由页面内ajax访问的接口发起了网络请求,这也显然证明了你是一个可疑的爬虫。知名电商网站Amazon就是采用的这种防御策略。

以上则是基于服务端校验爬虫程序,可以玩出的一些套路手段。

基于客户端js运行时的检测

现代浏览器赋予了JavaScript强大的能力,因此我们可以把页面的所有核心内容都做成js异步请求 ajax 获取数据后渲染在页面中的,这显然提高了爬虫抓取内容的门槛。依靠这种方式,我们把对抓取与反抓取的对抗战场从服务端转移到了客户端浏览器中的js运行时,接下来说一说结合客户端js运行时的爬虫抓取技术。

刚刚谈到的各种服务端校验,对于普通的python、java语言编写的http抓取程序而言,具有一定的技术门槛,毕竟一个web应用对于未授权抓取者而言是黑盒的,很多东西需要一点一点去尝试,而花费大量人力物力开发好的一套抓取程序,web站作为防守一方只要轻易调整一些策略,攻击者就需要再次花费同等的时间去修改爬虫抓取逻辑。

此时就需要使用headless browser了,这是什么技术呢?其实说白了就是,让程序可以操作浏览器去访问网页,这样编写爬虫的人可以通过调用浏览器暴露出来给程序调用的api去实现复杂的抓取业务逻辑。

其实近年来这已经不算是什么新鲜的技术了,从前有基于webkit内核的PhantomJS,基于Firefox浏览器内核的SlimerJS,甚至基于IE内核的trifleJS,有兴趣可以看看这里这里 是两个headless browser的收集列表。

这些headless browser程序实现的原理其实是把开源的一些浏览器内核C++代码加以改造和封装,实现一个简易的无GUI界面渲染的browser程序。但这些项目普遍存在的问题是,由于他们的代码基于fork官方webkit等内核的某一个版本的主干代码,因此无法跟进一些最新的css属性和js语法,并且存在一些兼容性的问题,不如真正的release版GUI浏览器运行得稳定。

这其中最为成熟、使用率最高的应该当属 PhantonJS 了,对这种爬虫的识别我之前曾写过一篇博客,这里不再赘述。PhantomJS存在诸多问题,因为是单进程模型,没有必要的沙箱保护,浏览器内核的安全性较差。另外,该项目作者已经声明停止维护此项目了。

如今Google Chrome团队在Chrome 59 release版本中开放了headless mode api,并开源了一个基于Node.js调用的headless chromium dirver库,我也为这个库贡献了一个centos环境的部署依赖安装列表

Headless Chrome可谓是Headless Browser中独树一帜的大杀器,由于其自身就是一个chrome浏览器,因此支持各种新的css渲染特性和js运行时语法。

基于这样的手段,爬虫作为进攻的一方可以绕过几乎所有服务端校验逻辑,但是这些爬虫在客户端的js运行时中依然存在着一些破绽,诸如:

基于plugin对象的检查

if(navigator.plugins.length === 0) {
    console.log('It may be Chrome headless');
}

基于language的检查

if(navigator.languages === '') {
    console.log('Chrome headless detected');
}

基于webgl的检查

var canvas = document.createElement('canvas');
var gl = canvas.getContext('webgl');

var debugInfo = gl.getExtension('WEBGL_debug_renderer_info');
var vendor = gl.getParameter(debugInfo.UNMASKED_VENDOR_WEBGL);
var renderer = gl.getParameter(debugInfo.UNMASKED_RENDERER_WEBGL);

if(vendor == 'Brian Paul' && renderer == 'Mesa OffScreen') {
    console.log('Chrome headless detected');
}

基于浏览器hairline特性的检查

if(!Modernizr['hairline']) {
    console.log('It may be Chrome headless');
}

基于错误img src属性生成的img对象的检查

var body = document.getElementsByTagName('body')[0];
var image = document.createElement('img');
image.src = 'http://iloveponeydotcom32188.jg';
image.setAttribute('id', 'fakeimage');
body.appendChild(image);
image.onerror = function(){
    if(image.width == 0 && image.height == 0) {
        console.log('Chrome headless detected');
    }
}

基于以上的一些浏览器特性的判断,基本可以通杀市面上大多数 Headless Browser 程序。在这一层面上,实际上是将网页抓取的门槛提高,要求编写爬虫程序的开发者不得不修改浏览器内核的C++代码,重新编译一个浏览器,并且,以上几点特征是对浏览器内核的改动其实并不小,如果你曾尝试过编译Blink内核Gecko内核你会明白这对于一个“脚本小子”来说有多难~

更进一步,我们还可以基于浏览器的 UserAgent 字段描述的浏览器品牌、版本型号信息,对js运行时、DOM和BOM的各个原生对象的属性及方法进行检验,观察其特征是否符合该版本的浏览器所应具备的特征。

这种方式被称为 浏览器指纹检查 技术,依托于大型web站对各型号浏览器api信息的收集。而作为编写爬虫程序的进攻一方,则可以在 Headless Browser 运行时里预注入一些js逻辑,伪造浏览器的特征。

另外,在研究浏览器端利用js api进行 Robots Browser Detect 时,我们发现了一个有趣的小技巧,你可以把一个预注入的js函数,伪装成一个Native Function,来看看下面代码:

var fakeAlert = (function(){}).bind(null);
console.log(window.alert.toString()); // function alert() { [native code] }
console.log(fakeAlert.toString()); // function () { [native code] }

爬虫进攻方可能会预注入一些js方法,把原生的一些api外面包装一层proxy function作为hook,然后再用这个假的js api去覆盖原生api。如果防御者在对此做检查判断时是基于把函数toString之后对[native code]的检查,那么就会被绕过。所以需要更严格的检查,因为bind(null)伪造的方法,在toString之后是不带函数名的,因此你需要在toString之后检查函数名是否为空。

这个技巧有什么用呢?这里延伸一下,反抓取的防御者有一种Robot Detect的办法是在js运行时主动抛出一个alert,文案可以写一些与业务逻辑相关的,正常的用户点确定按钮时必定会有一个1s甚至更长的延时,由于浏览器里alert会阻塞js代码运行(实际上在v8里他会把这个isolate上下文以类似进程挂起的方式暂停执行),所以爬虫程序作为攻击者可以选择以上面的技巧在页面所有js运行以前预注入一段js代码,把alertpromptconfirm等弹窗方法全部hook伪造。如果防御者在弹窗代码之前先检验下自己调用的alert方法还是不是原生的,这条路就被封死了。

反爬虫的银弹

目前的反抓取、机器人检查手段,最可靠的还是验证码技术。但验证码并不意味着一定要强迫用户输入一连串字母数字,也有很多基于用户鼠标、触屏(移动端)等行为的行为验证技术,这其中最为成熟的当属Google reCAPTCHA,基于机器学习的方式对用户与爬虫进行区分。

基于以上诸多对用户与爬虫的识别区分技术,网站的防御方最终要做的是封禁ip地址或是对这个ip的来访用户施以高强度的验证码策略。这样一来,进攻方不得不购买ip代理池来抓取网站信息内容,否则单个ip地址很容易被封导致无法抓取。抓取与反抓取的门槛被提高到了ip代理池经济费用的层面。

机器人协议

除此之外,在爬虫抓取技术领域还有一个“白道”的手段,叫做robots协议。你可以在一个网站的根目录下访问/robots.txt,比如让我们一起来看看github的机器人协议AllowDisallow声明了对各个UA爬虫的抓取授权。

不过,这只是一个君子协议,虽具有法律效益,但只能够限制那些商业搜索引擎的蜘蛛程序,你无法对那些“野爬爱好者”加以限制。

写在最后

对网页内容的抓取与反制,注定是一个魔高一尺道高一丈的猫鼠游戏,你永远不可能以某一种技术彻底封死爬虫程序的路,你能做的只是提高攻击者的抓取成本,并对于未授权的抓取行为做到较为精确的获悉。

这篇文章中提到的对于验证码的攻防其实也是一个较为复杂的技术难点,在此留一个悬念,感兴趣可以加关注期待后续文章进行详细阐述。

另外,欢迎对抓取方面感兴趣的朋友关注我的一个开源项目webster, 项目以Node.js 结合Chrome headless模式实现了一个高可用性网络爬虫抓取框架,借以chrome对页面的渲染能力, 可以抓取一个页面中 所有的js及ajax渲染的异步内容;并结合redis实现了一个任务队列,使得爬虫程序可以方便的进行横向、纵向的分布式扩展。部署起来很方便,我已经为webster提供了一个官方版的基础运行时docker镜像,如果你想先睹为快也可以试试这个webster demo docker镜像

查看原文

赞 102 收藏 545 评论 11

在路上 关注了用户 · 2017-12-11

星空幻颖 @yanying

QQ:1403348978(严颖)

关注 153

在路上 赞了文章 · 2017-12-11

PHP中被忽略的性能优化利器:生成器

如果是做Python或者其他语言的小伙伴,对于生成器应该不陌生。但很多PHP开发者或许都不知道生成器这个功能,可能是因为生成器是PHP 5.5.0才引入的功能,也可以是生成器作用不是很明显。但是,生成器功能的确非常有用。

优点

直接讲概念估计你听完还是一头雾水,所以我们先来说说优点,也许能勾起你的兴趣。那么生成器有哪些优点,如下:

  • 生成器会对PHP应用的性能有非常大的影响
  • PHP代码运行时节省大量的内存
  • 比较适合计算大量的数据

那么,这些神奇的功能究竟是如何做到的?我们先来举个例子。

概念引入

首先,放下生成器概念的包袱,来看一个简单的PHP函数:

function createRange($number){
    $data = [];
    for($i=0;$i<$number;$i++){
        $data[] = time();
    }
    return $data;
}

这是一个非常常见的PHP函数,我们在处理一些数组的时候经常会使用。这里的代码也非常简单:

  1. 我们创建一个函数。
  2. 函数内包含一个for循环,我们循环的把当前时间放到$data里面
  3. for循环执行完毕,把$data返回出去。

下面没完,我们继续。我们再写一个函数,把这个函数的返回值循环打印出来:

$result = createRange(10); // 这里调用上面我们创建的函数
foreach($result as $value){
    sleep(1);//这里停顿1秒,我们后续有用
    echo $value.'<br />';
}

我们在浏览器里面看一下运行结果:

图片描述

这里非常完美,没有任何问题。(当然sleep(1)效果你们看不出来)

思考一个问题

我们注意到,在调用函数createRange的时候给$number的传值是10,一个很小的数字。假设,现在传递一个值10000000(1000万)。

那么,在函数createRange里面,for循环就需要执行1000万次。且有1000万个值被放到$data里面,而$data数组在是被放在内存内。所以,在调用函数时候会占用大量内存。

这里,生成器就可以大显身手了。

创建生成器

我们直接修改代码,你们注意观察:

function createRange($number){
    for($i=0;$i<$number;$i++){
        yield time();
    }
}

看下这段和刚刚很像的代码,我们删除了数组$data,而且也没有返回任何内容,而是在time()之前使用了一个关键字yield

使用生成器

我们再运行一下第二段代码:

$result = createRange(10); // 这里调用上面我们创建的函数
foreach($result as $value){
    sleep(1);
    echo $value.'<br />';
}

图片描述

我们奇迹般的发现了,输出的值和第一次没有使用生成器的不一样。这里的值(时间戳)中间间隔了1秒。

这里的间隔一秒其实就是sleep(1)造成的后果。但是为什么第一次没有间隔?那是因为:

  • 未使用生成器时:createRange函数内的for循环结果被很快放到$data中,并且立即返回。所以,foreach循环的是一个固定的数组。
  • 使用生成器时:createRange的值不是一次性快速生成,而是依赖于foreach循环。foreach循环一次,for执行一次。

到这里,你应该对生成器有点儿头绪。

深入理解生成器

代码剖析

下面我们来对于刚刚的代码进行剖析。

function createRange($number){
    for($i=0;$i<$number;$i++){
        yield time();
    }
}

$result = createRange(10); // 这里调用上面我们创建的函数
foreach($result as $value){
    sleep(1);
    echo $value.'<br />';
}

我们来还原一下代码执行过程。

  1. 首先调用createRange函数,传入参数10,但是for值执行了一次然后停止了,并且告诉foreach第一次循环可以用的值。
  2. foreach开始对$result循环,进来首先sleep(1),然后开始使用for给的一个值执行输出。
  3. foreach准备第二次循环,开始第二次循环之前,它向for循环又请求了一次。
  4. for循环于是又执行了一次,将生成的时间戳告诉foreach.
  5. foreach拿到第二个值,并且输出。由于foreachsleep(1),所以,for循环延迟了1秒生成当前时间

所以,整个代码执行中,始终只有一个记录值参与循环,内存中也只有一条信息。

无论开始传入的$number有多大,由于并不会立即生成所有结果集,所以内存始终是一条循环的值。

概念理解

到这里,你应该已经大概理解什么是生成器了。下面我们来说下生成器原理。

首先明确一个概念:生成器yield关键字不是返回值,他的专业术语叫产出值,只是生成一个值

那么代码中foreach循环的是什么?其实是PHP在使用生成器的时候,会返回一个Generator类的对象。foreach可以对该对象进行迭代,每一次迭代,PHP会通过Generator实例计算出下一次需要迭代的值。这样foreach就知道下一次需要迭代的值了。

而且,在运行中for循环执行后,会立即停止。等待foreach下次循环时候再次和for索要下次的值的时候,for循环才会再执行一次,然后立即再次停止。直到不满足条件不执行结束。

实际开发应用

很多PHP开发者不了解生成器,其实主要是不了解应用领域。那么,生成器在实际开发中有哪些应用?

读取超大文件

PHP开发很多时候都要读取大文件,比如csv文件、text文件,或者一些日志文件。这些文件如果很大,比如5个G。这时,直接一次性把所有的内容读取到内存中计算不太现实。

这里生成器就可以派上用场啦。简单看个例子:读取text文件

图片描述

我们创建一个text文本文档,并在其中输入几行文字,示范读取。

<?php
header("content-type:text/html;charset=utf-8");
function readTxt()
{
    # code...
    $handle = fopen("./test.txt", 'rb');

    while (feof($handle)===false) {
        # code...
        yield fgets($handle);
    }

    fclose($handle);
}

foreach (readTxt() as $key => $value) {
    # code...
    echo $value.'<br />';
}

图片描述

通过上图的输出结果我们可以看出代码完全正常。

但是,背后的代码执行规则却一点儿也不一样。使用生成器读取文件,第一次读取了第一行,第二次读取了第二行,以此类推,每次被加载到内存中的文字只有一行,大大的减小了内存的使用。

这样,即使读取上G的文本也不用担心,完全可以像读取很小文件一样编写代码。

推荐一个我们团队自己开发的针对开发者的网址导航:笔点导航 - 用心做最简洁的网址导航

  1. 可以自定义网址
  2. 可以自定义分类
  3. 分类可以标记颜色
  4. 自定义皮肤
  5. 自定义搜索
  6. 网址拖拽排序
  7. 自定义插件小模块

图片描述

查看原文

赞 206 收藏 545 评论 43

在路上 发布了文章 · 2017-10-23

mysql强制索引说明

问题

生成环境,同一条sql在不同的从库执行,产生的执行计划不同,一个使用了索引,一个未使用索引

explain SELECT * FROM `database`.`table` FORCE INDEX(create_time) WHERE create_time >= 1508360400 and create_time <= 1508444806 ORDER BY create_time asc LIMIT 4000, 1000;

原因分析

  1. 分析是否是取值limit太大,超过count的1/3,Innodb引擎不使用索引。经分析共计有6000多条数据,索引这个原因可以排除
  2. 相同的sql在不同的从库执行,一个未使用索引,分析是索引文件或者表的碎片导致,后咨询阿里DBA给分析是表的碎片问题导致产生的执行计划不正常

解决方案

  1. 方案1:执行OPTIMIZE TABLE修复碎片或者执行ALTER TABLE foo ENGINE=InnoDB,以上两种操作都会锁表,对于数据量大,且业务高峰期执行需要慎重
  2. 方案2:强制索引,也就是FORCE index create_time,强制mysql 引擎使用索引,这里需要注意一下,当使用强制索引时,存储引擎会检查强制索引是否可用,如果不可用,还需要扫描表来判断那种执行计划,官方说明:

    The FORCE INDEX hint acts like USE INDEX (index_list), with the addition that a table scan is assumed to be very expensive. In other words, a table scan is used only if there is no way to use one of the named indexes to find rows in the table.

也不用担心有副作用,如果强制索引可用,正好能提要索引选择的效率

参考链接:

http://blog.csdn.net/u0115755...

https://dev.mysql.com/doc/ref...

查看原文

赞 1 收藏 0 评论 0

在路上 关注了问题 · 2017-08-07

解决MySQL 执行计划(Using where,Using index 和 Using index condition)

关于执行计划的 Extra 字段,对这几个取值有一些疑惑,我说一下我的大致理解。

  1. Using where:表示优化器需要通过索引回表查询数据;

  2. Using index:表示直接访问索引就足够获取到所需要的数据,不需要通过索引回表;

  3. Using index condition:在5.6版本后加入的新特性(Index Condition Pushdown);
    clipboard.png
    Using index condition 会先条件过滤索引,过滤完索引后找到所有符合索引条件的数据行,随后用 WHERE 子句中的其他条件去过滤这些数据行;

  4. Using where && Using index:这个确实不了解它和 Using index condition 的区别。

然后,我在 MySQL 的示例数据库 Sakila 中做了一些测试,但是结果却让我感到非常疑惑:

测试使用 Sakila.rental 表,表中的 customer_id 建立了名为 idx_fk_customer_id 索引。

-- 第一个 SQL 语句
EXPLAIN SELECT customer_id FROM rental WHERE customer_id>=300;

clipboard.png

结果是使用了 idx_fk_customer_id 索引,但是 Extra 信息竟然为 Using where;Using index;
在这个 SQL 语句中,SELECT 子句 和 WHERE 子句不是都是可以从索引中过滤并取得的吗,为什么Extra 的值不是 Using index 呢?

-- 第二个 SQL 语句
EXPLAIN SELECT * FROM rental WHERE customer_id>=373;

clipboard.png

这回更奇怪了,因为 SELECT 语句中包含索引中不存在的数据,所以需要通过索引回表查询数据,所以 Extra 为 Using where 我可以理解,但是这里竟然 type 竟然为 ALL,也就说执行计划中使用的是全表扫描!这又是为什么呢?

-- 第三个 SQL 语句
EXPLAIN SELECT customer_id FROM rental WHERE customer_id>=373 AND customer_id<400;

clipboard.png

这个语句的 Extra 值同样为 Using where;Using index

-- 第四个 SQL 语句
EXPLAIN SELECT * FROM rental WHERE customer_id>=373 AND customer_id<400;

clipboard.png

这个语句的执行计划就比较好理解了,先使用 cusomter_id>373 或者 customer_id<400 中的一个条件过滤索引,过滤完索引后,通过索引回表扫描并再次过滤掉一部分信息,随后返回最终的结果,Extra 为 Using index condition.

还望各位大神能不吝解答,或者您可以指点我最关心的三个问题:
1.Using where && Using index 和 Using index condition 的区别;

2.为什么EXPLAIN SELECT customer_id FROM rental WHERE customer_id>=300;会使用索引,
而 EXPLAIN SELECT * FROM rental WHERE customer_id>=300; 则不会使用索引呢?

EXPLAIN SELECT * FROM rental WHERE customer_id>=300 AND customer_id<=350;会使用索引
EXPLAIN SELECT * FROM rental WHERE customer_id>=300 AND customer_id<=476;则不会使用索引
索引对 RANGE 值范围有要求吗?
customer_id 是 SMALLINT(5) 类型的

关注 23 回答 6

在路上 关注了专栏 · 2017-08-02

PHP 开发之旅

分享PHP编程的实践经验, 不限于PHP

关注 56

在路上 关注了用户 · 2017-08-02

zhaot @zhaot_589fb309098c2

努力让技术精进,灵魂有趣

关注 87

在路上 分享了头条 · 2017-06-14

我自己的PhpStorm配置文件,修改过主题配色和快捷键,下载地址见网盘:https://pan.baidu.com/s/1pKQuTYF 除了常用的快捷键:http://www.jianshu.com/p/dd97...特殊设置的:command + O : 搜索/跳转 类和函数command + R : 在类中搜索、跳转函数command + D :选中...

赞 0 收藏 0 评论 0

认证与成就

  • 获得 92 次点赞
  • 获得 12 枚徽章 获得 0 枚金徽章, 获得 4 枚银徽章, 获得 8 枚铜徽章

擅长技能
编辑

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2013-05-29
个人主页被 635 人浏览