Quantcast
Channel: IT瘾技术推荐
Viewing all 330 articles
Browse latest View live

Spring Cloud Netflix构建微服务入门实践

$
0
0

在使用Spring Cloud Netflix构建微服务之前,我们先了解一下Spring Cloud集成的Netflix OSS的基础组件Eureka,对于Netflix的其他微服务组件,像Hystrix、Zuul、Ribbon等等本文暂不涉及,感兴趣可以参考官网文档。这里,我们用最基础的Eureka来构建一个最基础的微服务应用,来演示如何构建微服务,了解微服务的基本特点。

Eureka

Eureka是Netflix开源的一个微服务注册组件,提供服务发现特性,它是一个基于REST的服务,主要具有如下功能:

  • 支持服务注册和发现
  • 具有Load Balance和Failover的功能
  • 在进行服务调用过程中,无需知道目标服务的主机(IP)和端口,只要知道服务名就可以实现调用

通过Netfix在Github上的文档,我们看一下Eureka的基本架构,如下图所示:
eureka_architecture
Eureka主要包含如下两个核心组件:

  • Eureka Server

Eureka Server是服务注册的服务端组件,负责管理Eureka Client注册的服务,提供服务发现的功能。它支持集群模式部署,集群部署模式中,多个Eureka Server之间会同步服务注册数据,能够保证某一个Eureka Server因为故障挂掉,仍能对外提供注册服务的能力。因为最初在Netflix,Eureka主要用在AWS Cloud上,用作定位服务、Load Balance和Failover,在AWS Cloud上,Eureka支持在多个Region中部署Eureka Server而构建一个注册中心集群,从而实现了服务注册中心的高可用性。

  • Eureka Client

Eureka Client是Eureka Server客户端组件库,可以基于它向Eureka Server注册服务,供服务调用方调用;也可以是一个服务调用方,通过检索服务并调用已经注册的服务。如上图所示,Application Service和Application Client都是基于Eureka Client开发的使用Eureka Server的服务。另外,Eureka Client提供了内置的Load Balancer,实现了基本的Round-robin模式的负载均衡。

Spring Cloud Netflix

Spring Cloud Netflix提供了对Netflix OSS的集成,同时还使用了Spring Boot,能够极大地简化微服务程序的开发。使用Spring Cloud提供的基本注解,就能非常方便的使用Netfix OSS基本组件。
要想使用Spring Cloud Eureka,只需要在Maven POM文件中加入如下依赖管理配置即可:

<dependencyManagement><dependencies><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-netflix</artifactId><version>1.0.7.RELEASE</version><type>pom</type><scope>import</scope></dependency></dependencies></dependencyManagement>

关于如何使用注解,我们会在下面的实践中,详细说明。

构建微服务实践

我们构建一个简单的微服务应用,能够实现服务注册,服务调用的基本功能。计划实现的微服务应用,交互流程如下图所示:
eureka-service-interaction
上图中,我们假设Eureka Client并没有缓存Eureka Server中注册的服务,而是每次都需要通过Eureka Server来查找并映射目标服务。上图所示的微服务应用,具有如下服务组件:

  • 两个Eureka Server实例组成的服务发现集群

通过Spring Cloud实现,只需要使用注解配置即可,代码如下所示:

package org.shirdrn.springcloud.eureka.server;

import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.builder.SpringApplicationBuilder;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;

@EnableEurekaServer
@SpringBootApplication
public class MyEurekaServer {

    public static void main(String[] args) {
        new SpringApplicationBuilder(MyEurekaServer.class).web(true).run(args);
    }
}

部署两个Eureka Server的代码是相同的,其中,对应的配置文件application.yml内容不同,示例如下所示:

server:
  port: 3300
spring:
  application:
    name: my-eureka-server
eureka:
  client:
    serviceUrl:
      defaultZone: http://localhost:3300/eureka/,http://localhost:3301/eureka/
  instance:
    metadataMap:
      instanceId: ${spring.application.name}:${spring.application.instance_id:${random.value}}

另一个只需要改一下server.port为3301即可。

  • 具有两个实例的Greeting Service服务

该示例服务,只是提供一个接口,能够给调用方返回调用结果,实现代码,如下所示:

package org.shirdrn.springcloud.eureka.applicationservice.greeting;

import org.springframework.boot.autoconfigure.EnableAutoConfiguration;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.builder.SpringApplicationBuilder;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RestController;

@SpringBootApplication
@EnableEurekaClient
@RestController
@EnableAutoConfiguration
public class GreeingService {

    @RequestMapping(method = RequestMethod.GET, value = "/greeting/{name}")
    public String greet(@PathVariable("name") String name) {
        return "::01:: Hello, " + name + "!";
    }

    public static void main(String[] args) {
        new SpringApplicationBuilder(GreeingService.class).web(true).run(args);
    }
}

为了能够观察,Greeting Service的两个实例,能够在调用的时候实现Round-robin风格的负载均衡,特别在返回的结果中增加了标识来区分。
对应的配置文件application.properties内容,除了对应的端口和服务实例名称不同,其它都相同,示例如下所示:

server.port=9901
spring.application.name = greeting.service
eureka.instance.metadataMap.instanceId = ${spring.application.name}:instance-9901
eureka.client.serviceUrl.defaultZone = http://localhost:3300/eureka/,http://localhost:3301/eureka/

这样就可以在启动时注册到Eureka Server中。

  • 一个名称为Application Caller的服务,需要调用Greeting Service服务

该服务和上面的服务类似,只是在其内部实现了对远程服务的调用,我们的实现代码如下所示:

package org.shirdrn.springcloud.eureka.applicationclient.caller;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.CommandLineRunner;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.builder.SpringApplicationBuilder;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;
import org.springframework.cloud.netflix.feign.EnableFeignClients;
import org.springframework.stereotype.Component;
import org.springframework.web.client.RestTemplate;

@SpringBootApplication
@EnableEurekaClient
@EnableFeignClients
public class Application {

    public static void main(String[] args) {
        new SpringApplicationBuilder(Application.class)
                .web(false)
                .run(args);
    }
}

@Component
class RestTemplateExample implements CommandLineRunner {

    @Autowired
    private RestTemplate restTemplate;
    private static final String GREETING_SERVICE_URI = "http://greeting.service/greeting/{name}";  // 通过服务名称来调用,而不需要知道目标服务的IP和端口

    @Override
    public void run(String... strings) throws Exception {
        while(true) {
            String greetingSentence = this.restTemplate.getForObject(
                    GREETING_SERVICE_URI,
                    String.class,
                    "Dean Shi"); // 透明调用远程服务
            System.out.println("Response result: " + greetingSentence);

            Thread.sleep(5000);
        }
    }
}

对应的配置文件application.properties内容,如下所示:

server.port=9999
spring.application.name = application.client.caller
eureka.instance.metadataMap.instanceId = ${spring.application.name}:instance-9999
eureka.client.serviceUrl.defaultZone = http://localhost:3300/eureka/,http://localhost:3301/eureka/

启动并验证微服务应用

上面已经实现了该示例微服务应用的全部组件,先可以启动各个服务组件了。启动顺序如下所示:

  1. 启动两个Eureka Server
  2. 启动两个Greeting Service
  3. 启动服务消费应用Application Call

可以通过Web页面查看Eureka Server控制台,如下图所示:
eureka-web-console
多次启动Application Call应用,就可以通过查看Greeting Service服务的日志,可以看到服务被调用,而且实现了基础的Round-robin负载均衡,日志如下所示:

Response result: ::02:: Hello, Dean Shi!
Response result: ::01:: Hello, Dean Shi!
Response result: ::02:: Hello, Dean Shi!
Response result: ::01:: Hello, Dean Shi!
Response result: ::02:: Hello, Dean Shi!
Response result: ::01:: Hello, Dean Shi!

我们实现示例微服务应用,验证后符合我们的期望。
上面微服务应用的实现代码及其配置,可以查看我的Github: https://github.com/shirdrn/springcloud-eureka-demo.git

参考链接


Android优化

$
0
0

I. 网络相关

更多网络优化,可参考:  Android网络

  • http头信息带Cache-Control域 确定缓存过期时间 防止重复请求
  • 直接用IP直连,不用域名,策略性跟新本地IP列表。 – DNS解析过程耗时在百毫秒左右,并且还有可能存在DNS劫持。
  • 图片、JS、CSS等静态资源,采用CDN(当然如果是使用7牛之类的服务就已经给你搭建布置好了)
  • 全局图片处理采用漏斗模型全局管控,所请求的图片大小最好依照业务大小提供/最大不超过屏幕分辨率需要,如果请求原图,也不要超过 GL10.GL_MAX_TEXTURE_SIZE
  • 全局缩略图直接采用webp,在尽可能不损失图片质量的前提下,图片大小与png比缩小30% ~ 70%
  • 如果列表里的缩略图服务器处理好的小图,可以考虑直接在列表数据请求中,直接以base64在列表数据中直接带上图片(国内还比较少,海外有些这种做法,好像web端比较常见)
  • 轮询或者socket心跳采用系统 AlarmManager提供的闹钟服务来做,保证在系统休眠的时候cpu可以得到休眠,在需要唤醒时可以唤醒(持有cpu唤醒锁)
  • 可以通过将零散的网路的请求打包进行一次操作,避免过多的无线信号引起电量消耗。

1. 传输数据格式选择

  • 如果是需要全量数据的,考虑使用 Protobuffers (序列化反序列化性能高于json),并且考虑使用 nano protocol buffer
  • 如果传输回来的数据不需要全量读取,考虑使用 Flatbuffers (序列化反序列化几乎不耗时,耗时是在读取对象时(就这一部分如果需要优化,可以参看 Flatbuffer Use Optimize

2. 输入流

使用具有缓存策略的输入流

建议替换为
InputStreamBufferedInputStream
ReaderBufferedReader

II. 基础相关

1. 数据结构

如果已知大概需要多大,就直接给初始大小,减少扩容时额外开销。

  • ArrayList: 里面就一数组,内存小,有序取值快,扩容效率低
  • LinkedList: 里面就一双向链表,内存大,随机插入删除快,扩容效率高。
  • HashSet: 里面就一个 HashMap,用key对外存储,目的就是不允许重复元素。
  • ConcurrentHashMap: 线程安全,采用细分锁,锁颗粒更小,并发性能更优
  • Collections.synchronizedMap: 线程安全,采用当前对象作为锁,颗粒较大,并发性能较差。
  • SparseArraySparseBooleanArraySparseIntArray: 针对Key为 IntBoolean进行了优化,采用二分法查找,简单数组存储。相比 HashMap而言, HashMap每添加一个数据,大约会需要申请额外的32字节的数据,因此 Sparsexxx在内存方面的开销会小很多。

2. 编码习惯

  • 尽量简化,不要做不需要的操作。
  • 尽量避免分配内存(创建对象): 1) 如果一个方法返回一个 String,并且这个方法的返回值始终都是被用来 append到一个 StringBuffer上,就改为传入 StringBuffer直接 append上去,避免创建一个短生命周期的临时对象;2) 如果使用的字符串是截取自某一个字符串,就直接从那个字符串上面 substring,不要拷贝一份,因为通过 substring虽然创建了新的 String对象,但是共享了里面的 char数组中的 char对象,减少了这块对象的创建;量使用多个一维数组,其性能高于多维数组; int数组性能远大于 Integer数组性能;
  • 如果你确定不需要访问类成员,让方法 static,这样调用时可以提升15%~20%的速度,因为不需要切换对象状态。
  • 如果某个参数是常量,别忘了使用 static final,这样可以让 Class首次初始化时,不需要调用 <clinit>来创建 static方法,而是在编译时就直接将常量替换代码中使用的位置。
  • Android开发中,类内尽量避免通过 get/set访问成员变量,虽然这在语言的开发中是一个好的习惯,但是Android虚拟机中,对方法的调用开销远大于对变量的直接访问。在没有JIT的情况下,直接的变量访问比调用方法快3倍,在JIT下,直接的变量访问更是比调用方法快7倍!
  • 当内部类需要访问外部类的私有 方法/变量时,考虑将这些外部类的私有 方法/变量改用包可见的方式。首先在编写代码的时候,通过内部类访问外部类的私有 方法/变量是合法的,但是在编译的时候为了满足这个会将需要被内部类访问的私有 方法/变量封装一层包可见的方法,实现让内部类访问这些私有的 方法/变量,根据前面我们有提到说方法的调用开销大于变量的调用,因此这样使得性能变差,所以我们在编码的时候可以考虑直接将需要被内部类调用的外部类私有 方法/变量,改为包可见。
  • 尽量少使用 float。在很多现代设备中, double的性能与 float的性能几乎没有差别,但是从大小上面 doublefloat的两倍的大小。
  • 尽量考虑使用整型而非浮点数,在较好的Android设备中,浮点数比整型慢一倍。
  • 尽量不要使用除法操作,有很多处理器有乘法器,但是没有除法器,也就是说在这些设备中需要将除法分解为其他的计算方式速度会比较慢。
  • 尽量使用系统sdk中提供的方法,而非自己去实现。如 String.indexOf()相关的API,Dalvik将会替换为内部方法; System.arraycopy()方法在Nexus One手机上,会比我们上层写的类似方法的执行速度快9倍。
  • 谨慎编写native,性能不一定更好,Native并不是用于使得性能更好,而是用于有些已经存在的库是使用native语言实现的,我们需要引入Android,这时才使用。1) 需要多出开销在维持Java-native的通信;2) 在native中创建的资源由于在native heap上面,因此需要主动的释放;3) 需要对不同的处理器架构进行支持,存在明显的兼容性问题需要解决。
  • 在没有JIT的设备中,面向接口编程的模式(如 Map map),相比直接访问对象类(如 HashMap map),会慢6%,但是在存在JIT的设备中,两者的速度差不多。但是内存占用方面面向接口变成会消耗更多内存,因此如果你的面向接口编程不是十分的必要的情况下可以考虑不用。
  • 在没有JIT的设备中,访问本地化变量相对与成员变量会快20%,但是在存在JIT的设备中,两者速度差不多。
遍历优化

尽量使用 Iterable而不是通过长度判断来进行遍历。

// 这种性能是最差的,JIT也无法对其优化。
public void zero() {
    int sum = 0;
    for (int i = 0; i < mArray.length; ++i) {
        sum += mArray[i].mSplat;
    }
}
// 相对zero()来说,这种写法会更快些,在存在JIT的情况下速度几乎和two()速度一样快。
public void one() {
    int sum = 0;
    // 1) 通过本地化变量,减少查询,在不存在JIT的手机下,优化较明显。
    Foo[] localArray = mArray;
    // 2) 获取队列长度,减少每次遍历访问变量的长度,有效优化。
    int len = localArray.length;
    for (int i = 0; i < len; ++i) {
        sum += localArray[i].mSplat;
    }
}
// 在无JIT的设备中,是最快的遍历方式,在存在JIT的设备中,与one()差不多快。
public void two() {
    int sum = 0;
    for (Foo a : mArray) {
        sum += a.mSplat;
    }
}

III. 数据库相关

建多索引的原则: 哪个字段可以最快的 减少查询结果,就把该字段放在最前面

无法使用索引的情况

  • 操作符 BETWEENLIKEOR
  • 表达式
  • CASE WHEN

不推荐

  • 不要设计出索引是其他索引的前缀(没有意义)
  • 更新时拒绝直接全量更新,要更新哪列就put哪列的数据
  • 如果最频繁的是更新与插入,别建很多索引 (原本表就很小就也没必要建)
  • 拒绝用大字符串创建索引
  • 避免建太多索引,查询时可能就不会选择最好的来执行

推荐

  • 多使用整型索引,效率远高于字符串索引
  • 搜索时使用SQL参数( "?", parameter)代替字符串拼接(底层有特殊优化与缓存)
  • 查询需要多少就limit多少(如判断是否含有啥,就limit 1就行了嘛)
  • 如果出现很宽的列(如blob类型),考虑放在单独表中(在查询或者更新其他列数据时防止不必要的大数据i/o影响性能)

IV. JNI抉择

Android JVM相关知识,可参看:  ART、Dalvik

Android JNI、NDK相关知识,可参看:  NDK

JNI不一定显得更快,有些会更慢。

特点: 不用在虚拟机的框子下写代码

  • 可以调用更底层的高性能的代码库 – Good
  • 如果是Dalvik,将省去了由JIT编译期转为本地代码的这个步骤。 – Good
  • Java调用JNI的耗时较Java调用Java肯定更慢,虽然随着JDK版本的升级,差距已经越来越小(JDK1.6版本是5倍Java调用Java方法的耗时) – Bad
  • 内存不在Java Heap,没有OOM风险,有效减少gc。 – Good

一些重要的参数之类,也可以考虑放在Native层,保证安全性。参考:  Android应用程序通用自动脱壳方法研究

V. 多进程抉择

360 17个进程:  360手机卫士 Android开发 InfoQ视频 总结 ,但是考虑到多进程的消耗,我们更需要关注多个组件复用同一进程。
在没有做任何操作的空进程而言,其大约需要额外暂用1.4MB的内存。

  • 充分独立,解耦部分
  • 大内存(如临时展示大量图片的Activity)、无法解决的crash、内存泄漏等问题,考虑通过独立进程解决
  • 独立于UI进程,需要在后台长期存活的服务(参看 Android中线程、进程与组件的关系)
  • 非己方第三方库(无法保证稳定、性能等问题,并且独立组件),可考虑独立进程

最后,多进程存在的两个问题: 1. 由于进程间通讯或者首次调起进程的消耗等,带来的cpu、i/o等的资源竞争。2. 也许对于部分同事来说,会还有可读性问题吧,毕竟多了层IPC绕了点。

VI. UI层面

相关深入优化,可参看 Android绘制布局相关

对于卡顿相关排查推荐参看:  Android性能优化案例研究(上)Android性能优化案例研究(下)

  • 减少不必要的不透明背景相互覆盖,减少重绘,因为GPU不得不一遍又一遍的画这些图层
  • 保证UI线程一次完整的绘制(measure、layout、draw)不超过16ms(60Hz),否则就会出现掉帧,卡顿的现象
  • 在UI线程中频繁的调度中,尽量少的对象创建,减少gc等。
  • 分步加载(减少任务颗粒)、预加载、异步加载(区别出耗时任务,采用异步加载)

VII. 库推荐

可以参考Falcon Pro作者的推荐:  Falcon Pro 3如何完成独立开发演讲分析

1. 响应式编程

RxJava (响应式编程,代码更加简洁,异步处理更快快捷、异常处理更加彻底、数据管道理念)

相关了解可以参看:  RxJava

2. 图片加载:

3. 网络底层库:

Okhttp: 默认gzip、缓存、安全等

4. 网络基层:

Retrofit: 非常好用的REST Client,结合RxJava简单API实现、类型安全,简单快捷

5. 数据库层:

Realm: 效率极高(Falcon Pro 3的作者Joaquim用了该库以后,所有数据库操作都放到了UI线程)(基于TightDB,底层C++闭源,Java层开源,简单使用,性能远高于SQLite等)

6. Crash上报:

Fabric: 全面的信息(新版本还支持JNI Crash获取和上报)、稳定的数据、及时的通知、强大的反混淆(其实在混淆后有上传mapping)

7. 内存泄漏自动化检测

LeakCanary: 自动化泄漏检测与分析 ( 可以看看这个 LeakCanary使用总结Leakcanary Square的一款Android/Java内存泄漏检测工具)

8. 其他

VIII. 内存

根据设备可用内存的不同,每个设备给应用限定的Heap大小是有限的,当达到对应限定值还申请空间时,就会收到 OutOfMemoryError的异常。

1. 内存管理

Android根据不同的进程优先级,对不同进程进行回收来满足内存的供求,可以参照这篇文章:  Android中线程、进程与组件的关系
在后台进程的LRU队列中,除了LRU为主要的规则以外,系统也会根据杀死一个后台进程所获得的内存是否更多作为一定的参考依据,因此后台进程为了保活,尽量少的内存,尽可能的释放内存也是十分必要的。

  • 尽可能的缩短 Service的存活周期(可以考虑直接使用执行完任务直接关闭自己的 IntentService),也就是说在Service没有任何任务的时候,尽可能的将其关闭,以减少系统资源的浪费。
  • 可以通过系统服务 ActivityManager中的 getMemoryClass()获知当前设备允许每个应用大概可以有多少兆的内存使用(如果在 AndroidManifest设置了 largeHeap=true,使用 getLargeMemoryClass()获知),并且让应用中的内存始终低于这个值,避免OOM。
  • 相对于静态常量而言,通常 Enum枚举需要大于两倍的内存空间来存储相同的数据。
  • Java中的每个 class(或者匿名类)大约占用500字节。
  • 每个对象实例大约开销12~16字节的内存。

onTrimMemory()回调处理

监听 onTrimMemory()的回调,根据不同的内存等级,做相应的释放以此让系统资源更好的利用,以及自己的进程可以更好的保活。

当应用还在前台
  • TRIM_MEMORY_RUNNING_MODERATE: 当前应用还在运行不会被杀,但是设备可运行的内存较低,系统正在从后台进程的LRU列表中杀死进程其他进程。
  • TRIM_MEMORY_RUNNING_LOW: 当前应用还在运行不会被杀,但是设备可运行内存很低了,会直接影响当前应用的性能,当前应用也需要考虑释放一些无用资源。
  • TRIM_MEMORY_RUNNING_CRITICAL: 当前应用还在运行中,但是系统已经杀死了后台进程LRU队列中绝大多数的进程了,当前应用需要考虑释放所有不重要的资源,否则很可能系统就会开始清理服务进程,可见进程等。也就说,如果内存依然不足以支撑,当前应用的服务也很有可能会被清理掉。
TRIM_MEMORY_UI_HIDDEN

当回调回来的时候,说明应用的UI对用户不可见的,此时释放UI使用的一些资源。这个不同于 onStop()onStop()的回调,有可能仅仅是当前应用中进入了另外一个 Activity

当应用处于后台
  • TRIM_MEMORY_BACKGROUND: 系统已经处于低可用内存的情况,并且当前进程处于后台进程LRU队列队头附近,因此还是比较安全的,但是系统可能已经开始从LRU队列中清理进程了,此时当前应用需要释放部分资源,以保证尽量的保活。
  • TRIM_MEMORY_MODERATE: 系统处于低可用内存的情况,并且当前进程处于后台进程LRU队列中间的位置,如果内存进一步紧缺,当前进程就有可能被清理掉,需要进一步释放资源。
  • TRIM_MEMORY_COMPLETE: 系统处于低可用内存的情况,并且当前进程处于后天进程LRU队列队首的位置,如果内存进一步紧缺,下一个清理的就是当前进程,需要释放尽可能的资源来保活当前进程。在API14之前, onLowMemory()就相当于这个级别的回调。

2. 避免内存泄漏相关

  • 无法解决的泄漏(如系统底层引起的)移至独立进程(如2.x机器存在webview的内存泄漏)
  • 大图片资源/全屏图片资源,要不放在 assets下,要不放在 nodpi下,要不都带,否则缩放会带来额外耗时与内存问题
  • 4.x在 AndroidManifest中配置 largeHeap=true,一般dvm heep最大值可增大50%以上。但是没有特殊明确的需要,尽可能的避免这样设置,因为这样一来很可能隐藏了消耗了完全没有必要的内存的问题。
  • Activity#onDestory以后,遍历所有View,干掉所有View可能的引用(通常泄漏一个Activity,连带泄漏其上的View,然后就泄漏了大于全屏图片的内存)。
  • 万金油: 静态化内部类,使用 WeakReference引用外部类,防止内部类长期存在,泄漏了外部类的问题。

3. 图片

Android 2.3.x或更低版本的设备,是将所有的Bitmap对象存储在native heap,因此我们很难通过工具去检测其内存大小,在Android 3.0或更高版本的设备,已经调整为存储到了每个应用自身的Dalvik heap中了。

  • 全局统一 BitmapFactory#decode出口,捕获此处decode oom,控制长宽(小于屏幕分辨率大小 )
  • 如果采用RGB_8888 oom了,尝试RGB_565(相比内存小一半以上(w h2(bytes)))
  • 如果还考虑2.x机器的话,设置 BitmapFactory#optionsInNativeAlloc参数为true,此时decode的内存不会上报到dvm中,便不会oom。
  • 建议采用 lingochamp/QiniuImageLoader的方式,所有图片的操作都放到云端处理,本地默认使用Webp,并且获取的每个位置的图片,尽量通过精确的大小按需获取,避免内存没必要的消耗。

IX. 线程

X. 编译与发布

  • 考虑采用DexGuard,或ProGuard结合相关资源混淆来提高安全与包大小,参考:  DexGuard、Proguard、Multi-dex
  • 结合Gradle、Gitlab-CI 与Slack(Incoming WebHooks),快速实现,打相关git上打相关Tag,自动编相关包通知Slack。
  • 结合Gitlab-CI与Slack(Incoming WebHooks),快速实现,所有的push,Slack快速获知。
  • 结合Gradle中Android提供的 productFlavors参数,定义不同的variations,快速批量打渠道包
  • 迭代过程中,包定期做多纬度扫描,如包大小、字节码大小变化、红线扫描、资源变化扫描、相同测试用例耗电量内存等等,更多的可以参考  360手机卫士 Android开发 InfoQ视频 总结
  • 迭代过程中,对关键 Activity以及 Application对打开的耗时进行统计,观察其变化,避免因为迭代导致某些页面非预期的打开变慢。

XI. 工具

  • TraceView可以有效的更重一段时间内哪个方法最耗时,但是需要注意的是目前TraceView在录制过中,会关闭JIT,因此也许有些JIT的优化在TraceView过程被忽略了。
  • Systrace可以有效的分析掉帧的原因。
  • HierarchyViewer可以有效的分析View层级以及布局每个节点 measurelayoutdraw的耗时。

XII. 其他

  • final能用就用(高效: 编译器在调用 final方法时,会转入内嵌机制)
  • 懒预加载,如简单的 ListViewRecyclerView等滑动列表控件,停留在当前页面的时候,可以考虑直接预加载下个页面所需图片
  • 智能预加载,通过权重等方式结合业务层面,分析出哪些更有可能被用户浏览使用,然后再在某个可能的时刻进行预加载。如,进入朋友圈之前通过用户行为,智能预加载部分原图。
  • 做好有损体验的准备,在一些无法避免的问题面前做好有损体验(如,非UI进程crash,可以自己解决就不要让用户感知,或者UI进程crash了,做好场景恢复)
  • 做好各项有效监控:crash(注意还有JNI的)、anr(定期扫描文件)、掉帧(绘制监控、activity生命周期监控等)、异常状态监控(本地Log根据需要不同级别打Log并选择性上报监控)等
  • 文件存储推荐放在 /sdcard/Android/data/[package name]/里(在应用卸载时,会随即删除)( Context#getExternalFilesDir()),而非 /sdcard/根目录建文件夹(节操问题)
  • 通过gradle的 shrinkResourcesminifyEnabled参数可以简单快速的在编包的时候自动删除无用资源
  • 由于resources.arsc在api8以后,aapt中默认采用UTF-8编码,导致资源中大都是中文的resources.arsc相比采用UTF-16编码更大,此时,可以考虑aapt中指定使用UTF-16
  • 谷歌建议,大于10M的大型应用考虑安装到SD卡上:  App Install Location
  • 当然运维也是一方面:  Optimize Your App
  • 在已知并且不需要栈数据的情况下,就没有必要需要使用异常,或创建 Throwable生成栈快照是一项耗时的工作。
  • 需要十分明确发布环境以及测试环境,明确仅仅为了方便测试的代码以及工具在发布环境不会被带上。

相关文章

2017年你不能错过的Java类库

$
0
0
这篇文章是在我看过  Andres Almiray 的一篇 介绍文后,整理出来的。因为内容非常好,我便将它整理成参考列表分享给大家, 同时附上各个库的特性简介和示例。

请欣赏!

Guice

Guice (发音同 ‘juice’) ,是一个 Google 开发的轻量级依赖性注入框架,适合 Java 6 以上的版本。

# Typical dependency injection
public class DatabaseTransactionLogProvider implements Provider<TransactionLog> {
  @Inject Connection connection;

  public TransactionLog get() {
    return new DatabaseTransactionLog(connection);
  }
}
# FactoryModuleBuilder generates factory using your interface
public interface PaymentFactory {
   Payment create(Date startDate, Money amount);
 }
  GitHubJavaDoc使用指南FactoryModuleBuilder

OkHttp

HTTP是现代应用程序实现网络连接的途径,也是我们进行数据和媒体交换的工具。高效使用HTTP能使你的东西加载更快,并节省带宽。

OkHttp是一个非常高效的HTTP客户端,默认情况下:

  • 支持HTTP/2,允许对同一主机的请求共用一个套接字。
  • 如果HTTP/2 不可用,连接池会减少请求延迟。
  • 透明的GZIP可以减少下载流量。
  • 响应的缓存避免了重复的网络请求。
OkHttpClient client = new OkHttpClient();

String run(String url) throws IOException {
  Request request = new Request.Builder()
      .url(url)
      .build();

  Response response = client.newCall(request).execute();
  return response.body().string();
}
GitHubWebsite

Retrofit

Retrofit 是 Square 下的类型安全的 HTTP 客户端,支持 Android 和 Java 等,它能将你的 HTTP API 转换为 Java 接口。

Retrofit 将 HTTP API 转换为 Java 接口:

public interface GitHubService {
    @GET("users/{user}/repos")
    Call<List<Repo>listRepos(@Path("user") String user);
}
Retrofit 类实现 GitHubService 接口:
Retrofit retrofit = new Retrofit.Builder()
    .baseUrl("https://api.github.com/")
    .build();

GitHubService service = retrofit.create(GitHubService.class);
来自 GitHubService 的每个 Call 都能产生为远程 Web 服务产生一个异步或同步 HTTP 请求:
Call<List<Repo>> repos = service.listRepos("octocat");
GitHubWebsite

JDeferred

与JQuery类似的Java Deferred/Promise类库

  • Deferred 对象和 Promise
  • Promise 回调: .then(…).done(…).fail(…).progress(…).always(…)
  • 支持多个promises -  .when(p1, p2, p3, …).then(…)
  • Callable 和 Runnable -  wrappers.when(new Runnable() {…})
  • 使用 Executor 服务
  • 支持Java 泛型:  Deferred<Integer, Exception, Doubledeferred;deferred.resolve(10);deferred.reject(new Exception());, deferred.notify(0.80);,
  • 支持Android
  • Java 8 Lambda的友好支持

GitHu链接官方网站链接

RxJava

RxJava – JVM的响应式编程扩展 – 是一个为Java虚拟机编写的使用可观察序列的构建异步的基于事件的程序的类库。

它基于 观察者模式实现对数据/事件的序列的支持,并添加了一些操作符,允许你以声明式构建序列, 使得开发者无需关心底层的线程、同步、线程安全和并发数据结构。

RxJava最常见的一个用法就是在后台线程运行一些计算和网络请求,而在UI线程显示结果(或者错误):

Flowable.fromCallable(() -{
     Thread.sleep(1000); //  imitate expensive computation
     return "Done";
 })
   .subscribeOn(Schedulers.io())
   .observeOn(Schedulers.single())
   .subscribe(System.out::println, Throwable::printStackTrace);

 Thread.sleep(2000); // <--- wait for the flow to finish
GitHubWiki

MBassador

MBassador是一个实现了 发布-订阅模式的轻量级的,高性能的事件总线。它易于使用,并力求功能丰富,易于扩展,而同时又保证资源的高效利用和高性能。

MBassador的高性能的核心是一个专业的数据结构,它提供了非阻塞的读取器,并最小化写入器的锁争用,因此并发读写访问的性能衰减会是最小的。

  • 注解驱动的
  • 提供任何东西,慎重对待类型层次结构
  • 同步和异步的消息传递
  • 可配置的引用类型
  • 消息过滤
  • 封装的消息
  • 处理器的优先级
  • 自定义错误处理
  • 可扩展性
// Define your listener
class SimpleFileListener{
    @Handler
    public void handle(File msg){
      // do something with the file
    }
}

// somewhere else in your code
MBassador bus = new MBassador();
Object listener = new SimpleFileListener();
bus.subscribe (listener);
bus.post(new File("/tmp/smallfile.csv")).now();
bus.post(new File("/tmp/bigfile.csv")).asynchronously();
GitHubJavadoc

Lombok项目

使用注解来减少Java中的重复代码,比如getter,setters,非空检查,生成的Builder等。

  • val - 总算有了!无忧的final本地变量。
  • @NonNull - 或:我如何学会不再担心并爱上了非空异常(NullPointerException)。
  • @Cleanup - 自动的资源管理:安全调用你的close() 方法,无需任何麻烦。
  • @Getter / @Setter - 再也不用写  public int getFoo() {return foo;}了
  • @ToString - 无需启动调试器来检查你的字段:就让Lombok来为你生成一个toString方法吧!
  • @EqualsAndHashCode - 实现相等的判断变得容易了:它会从你的对象的字段里为你生成hashCode和equals方法的实现。
  • @NoArgsConstructor, @RequiredArgsConstructor and @AllArgsConstructor - 定做构造函数:为你生成各种各样的构造函数,包括无参的,每一个final或非空的字段作为一个参数的,或者每一个字段都作为参数的。
  • @Data - 所有的都同时生成:这是一个快捷方式,可以为所有字段生成 @ToString@EqualsAndHashCode@Getter注解,以及为所有非final的字段生成@Setter注解,以及生成 @RequiredArgsConstructor!
  • @Value - 声明一个不可变类变得非常容易。
  • @Builder - … 而且鲍伯是你叔叔:创建对象的无争议且奢华的接口!
  • @SneakyThrows - 在以前没有人抛出检查型异常的地方大胆的抛出吧!
  • @Synchronized - 正确的实现同步:不要暴露你的锁。
  • @Getter(lazy=true) 懒惰是一种美德!
  • @Log - 船长日志,星历24435.7: “那一行又是什么呢?”

GitHubWebsite

Java简单日志门面(SLF4J)

Java简单日志门面 (SLF4J) 为不同的日志框架(比如 java.util.logginglogbacklog4j)提供了简单的门面或者抽象的实现,允许最终用户在部署时能够接入自己想要使用的日志框架。

简言之,类库和其他嵌入式的组件都应该考虑采用SLF4J作为他们的日志需求,因为类库无法将它们对日志框架的选择强加给最终用户。另一方面,对于独立的应用来说,就不一定需要使用SLF4J。独立应用可以直接调用他们自己选择的日志框架。而对于 logback来说,这个问题是没有意义的,因为 logback是通过SLF4J来暴露其日志接口的。

WebsiteGitHubFAQ

JUnitParams

对测试进行参数化,还不错

    @Test
       @Parameters({"17, false", "22, true" })
       public void personIsAdult(int age, boolean valid) throws Exception {
         assertThat(new Person(age).isAdult(), is(valid));
       }
与标准的JUnit 参数化运行器的区别如下:

  • 更明确 – 参数实在测试方法的参数中,而不是在类的字段中
  • 更少的代码 – 你不需要用构造函数来设置参数
  • 你可以在同一个类混合使用参数化和非参数化的方法。
  • 参数可以通过一个CSV字符串或者一个参数提供类传入。
  • 参数提供类可以拥有尽可能多的参数提供方法,这样你可以给不同的用例进行分类。
  • 你可以拥有可以提供参数的测试方法 (再也不需要外部类或者静态类了)
  • 你可以在你的集成开发工具中看到实际的参数值(而在JUnit的Parametrised里,只有连续数目的参数)

官方网站GitHub快速入门

Mockito

Java里单元测试的非常棒(tasty)的模拟框架:

 //你可以模拟具体的类,而不只是接口
 LinkedList mockedList = mock(LinkedList.class);

 //打桩
 when(mockedList.get(0)).thenReturn("first");
 when(mockedList.get(1)).thenThrow(new RuntimeException());

 //以下代码打印出"first"字符串
 System.out.println(mockedList.get(0));

 //以下代码抛出运行时异
 System.out.println(mockedList.get(1));

 //以下代码打印出"null",因为get(999)没有被打桩
 System.out.println(mockedList.get(999));

 //尽管是可以验证一个打过桩的调用,但通常是多余的
 //如果你的代码关心get(0)返回值的内容,那么其他东西就会中断(往往在verify()执行之前就发生了)。
 //如果你的代码不关心get(0)返回值的内容,那么它就不应该被打桩。不相信吗?看看这里。
 verify(mockedList).get(0);
官方网站,  GitHub,  文档

Jukito

它结合了JUnit、Guice和Mockito的能力。 而且它还听起来像一门很酷的武术。

  • 极大的减少了诸如自动mock的样板,从而使测试更加易读。
  • 可以使得测试能够根据被测试的对象上的API的改变而弹性变化。
  • 标有@Inject注解的字段会被自动注入,不需要担心会遗忘掉它们
  • 使得将对象连接在一起变得容易,因此你可以将一个单元测试变成集成测试的一部分
@RunWith(JukitoRunner.class)
public class EmailSystemTest {

  @Inject EmailSystemImpl emailSystem;
  Email dummyEmail;

  @Before
  public void setupMocks(
      IncomingEmails incomingEmails,
      EmailFactory factory) {
    dummyEmail = factory.createDummy();
    when(incomingEmails.count()).thenReturn(1);
    when(incomingEmails.get(0)).thenReturn(dummyEmail);
  }

  @Test
  public void shouldFetchEmailWhenStarting(
      EmailView emailView) {
    // WHEN
    emailSystem.start();

    // THEN
    verify(emailView).addEmail(dummyEmail);
  }
}
GitHubWebsite

Awaitility

Awaitility是一个小型的Java领域专用语言(DSL),用于对异步的操作进行同步。

测试异步的系统是比较困难的。不仅需要处理线程、超时和并发问题,而且测试代码的本来意图也有可能被这些细节所蒙蔽。Awaitility是一个领域专用语言,可以允许你以一种简洁且易读的方式来表达异步系统的各种期望结果。

@Test
public void updatesCustomerStatus() throws Exception {
    // Publish an asynchronous event:
    publishEvent(updateCustomerStatusEvent);
    // Awaitility lets you wait until the asynchronous operation completes:
    await().atMost(5, SECONDS).until(customerStatusIsUpdated());
    ...
}
GitHub入门,  用户指南

Spock

企业级的测试和规范框架。

class HelloSpockSpec extends spock.lang.Specification {
  def "length of Spock's and his friends' names"() {
    expect:
    name.size() == length

    where:
    name     | length
    "Spock"  | 5"Kirk"   | 4"Scotty" | 6
  }
}
GitHubWebsite

WireMock

用于模拟HTTP服务的工具

  • 对HTTP响应进行打桩,可以匹配URL、header头信息和body内容的模式
  • 请求验证
  • 在单元测试里运行,但是是作为一个对立的进程或者一个WAR应用的形式
  • 可通过流畅的Java API、JSON文件和基于HTTP的JSON进行配置
  • 对stub的录制/回放
  • 故障注入
  • 针对每个请求的根据条件进行代理
  • 针对请求的检查和替换进行浏览器的代理
  • 有状态的行为模拟
  • 可配置的响应延迟
{"request": {"method": "GET","url": "/some/thing"
    },"response": {"status": 200,"statusMessage": "Everything was just fine!"
    }
}
GitHubWebsite

相关文章

SpringBoot的事务管理

$
0
0

Springboot内部提供的事务管理器是根据autoconfigure来进行决定的。

比如当使用jpa的时候,也就是pom中加入了spring-boot-starter-data-jpa这个starter之后(之前我们分析过 springboot的自动化配置原理)。

Springboot会构造一个JpaTransactionManager这个事务管理器。

而当我们使用spring-boot-starter-jdbc的时候,构造的事务管理器则是DataSourceTransactionManager。

这2个事务管理器都实现了spring中提供的PlatformTransactionManager接口,这个接口是spring的事务核心接口。

这个核心接口有以下这几个常用的实现策略:

  1. HibernateTransactionManager
  2. DataSourceTransactionManager
  3. JtaTransactionManager
  4. JpaTransactionManager

具体的PlatformTransactionManager继承关系如下:

spring-boot-starter-data-jpa这个starter会触发HibernateJpaAutoConfiguration这个自动化配置类,HibernateJpaAutoConfiguration继承了JpaBaseConfiguration基础类。

在JpaBaseConfiguration中构造了事务管理器:

@Bean
@ConditionalOnMissingBean(PlatformTransactionManager.class)
public PlatformTransactionManager transactionManager() {
    return new JpaTransactionManager();
}

spring-boot-starter-jdbc会触发DataSourceTransactionManagerAutoConfiguration这个自动化配置类,也会构造事务管理器:

@Bean
@ConditionalOnMissingBean(PlatformTransactionManager.class)
@ConditionalOnBean(DataSource.class)
public DataSourceTransactionManager transactionManager() {
    return new DataSourceTransactionManager(this.dataSource);
}

Spring的事务管理器PlatformTransactionManager接口中定义了3个方法:

// 基于事务的传播特性,返回一个已经存在的事务或者创建一个新的事务
TransactionStatus getTransaction(TransactionDefinition definition) throws TransactionException;

// 提交事务
void commit(TransactionStatus status) throws TransactionException;

// 回滚事务
void rollback(TransactionStatus status) throws TransactionException;

其中TransactionDefinition接口表示跟spring兼容的事务属性,比如传播行为、隔离级别、超时时间、是否只读等属性。

DefaultTransactionDefinition类是一个默认的TransactionDefinition实现,它的传播行为是PROPAGATION_REQUIRED(如果当前没事务,则创建一个,否则加入到当前事务中),隔离级别是数据库默认级别。

TransactionStatus接口表示事务的状态,比如事务是否是一个刚构造的事务、事务是否已经完成等状态。

下面这段代码就是传统事务的常见写法:

transaction.begin();
try {
    ...
    transaction.commit();
} catch(Exception e) {
    ...
    transaction.rollback();
} finally {

}

由于spring的事务操作被封装到了PlatformTransactionManager接口中,commit和rollback方法对应接口中的方法,begin方法在getTransaction方法中会被调用。

细心的读者发现文章前面构造事务管理器的时候都会加上这段注解:

@ConditionalOnMissingBean(PlatformTransactionManager.class)

也就是说如果我们手动配置了事务管理器,Springboot就不会再为我们自动配置事务管理器。

如果要使用多个事务管理器的话,那么需要手动配置多个:

@Configuration
public class DatabaseConfiguration {

    @Bean
    public PlatformTransactionManager transactionManager1(EntityManagerFactory entityManagerFactory) {
        return new JpaTransactionManager(entityManagerFactory);
    }

    @Bean
    public PlatformTransactionManager transactionManager2(DataSource dataSource) {
        return new DataSourceTransactionManager(dataSource);
    }

}

然后使用Transactional注解的时候需要声明是哪个事务管理器:

@Transactional(value="transactionManager1")
public void save() {
    doSave();
}

Spring给我们提供了一个TransactionManagementConfigurer接口,该接口只有一个方法返回PlatformTransactionManager。其中返回的PlatformTransactionManager就表示这是默认的事务处理器,这样在Transactional注解上就不需要声明是使用哪个事务管理器了。

参考资料:

http://www.cnblogs.com/davidwang456/p/4309038.html

http://blog.csdn.net/chjttony/article/details/6528344

可能感兴趣的文章

JVM诊断调优CheatSheet

$
0
0

常用Shell命令

  • 查看网络状况
     netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
  • 使用top去获取进程cpu使用率;使用/proc文件查看进程所占内存。
     #!/bin/bash
      for i in `ps -ef | egrep -v "awk|$0" | awk '/'$1'/{print $2}'`
      do
          mymem=`cat /proc/$i/status 2> /dev/null | grep VmRSS | awk '{print $2" " $3}'`
          cpu=`top -n 1 -b |awk '/'$i'/{print $9}'`
      done

常用JDK命令

  • 查看类的一些信息,如字节码的版本号、常量池等

    javap -verbose classname

  • 查看jvm进程

    jps

    jcmd -l

  • 查看进程的gc情况

    jstat -gcutil [pid] (显示总体情况)

    jstat -gc [pid] 1000 10(每隔1秒刷新一次 一共10次)

  • 查看jvm内存使用状况

    jmap -heap [pid]

  • 查看jvm内存存活的对象:

    jcmd [pid] GC.class_histogram

    jmap -histo:live [pid]

  • 把heap里所有对象都dump下来,无论对象是死是活

    jmap -dump:format=b,file=xxx.hprof [pid]

  • 先做一次full GC,再dump,只包含仍然存活的对象信息:

    jcmd [PID] GC.heap_dump [FILENAME]

    jmap -dump:format=b,live,file=xxx.hprof [pid]

  • 线程dump

    jstack [pid] #-m参数可以打印出native栈的信息

    jcmd Thread.print

    kill -3 [pid]

  • 查看目前jvm启动的参数

    jinfo -flags [pid] #有效参数

    jcmd [pid] VM.flags #所有参数

  • 查看对应参数的值

    jinfo -flag [flagName] [pid]

  • 启用/禁止某个参数

    jinfo -flag [+/-][flagName] [pid]

  • 设置某个参数

    jinfo -flag [flagName=value] [pid]

  • 查看所有可以设置的参数以及其默认值

    java -XX:+PrintFlagsInitial

第三方工具

======== awesome-scripts========

安装:

curl -s "https://raw.githubusercontent.com/superhj1987/awesome-scripts/master/self-installer.sh" | bash -s

使用:

  • 显示最繁忙的java线程: -c <要显示的线程栈数> -p <指定的Java Process>

    opscipts show-busy-java-threads [-c] [-p]

  • 使用greys跟踪方法耗时

    opscripts greys [@IP:PORT]

    ga?: trace [class] [method]

  • 显示当前cpu和内存使用状况,包括全局和各个进程的。

    opscripts show-cpu-and-memory

  • 进入jvm调试交互命令行,包含对java栈、堆、线程、gc等状态的查看

    opscripts jvm [pid]

JVM配置示例

-server #64位机器下默认
-Xms6000M #最小堆大小
-Xmx6000M #最大堆大小
-Xmn500M #新生代大小
-Xss256K #栈大小
-XX:PermSize=500M (JDK7)
-XX:MaxPermSize=500M (JDK7)
-XX:MetaspaceSize=128m  (JDK8)
-XX:MaxMetaspaceSize=512m(JDK8)
-XX:SurvivorRatio=65536
-XX:MaxTenuringThreshold=0 #晋升到老年代需要的存活次数,设置为0时,survivor区失去作用,一次minor gc,eden中存活的对象就会进入老年代,默认是15,使用CMS时默认是4
-Xnoclassgc #不做类的gc
#-XX:+PrintCompilation #输出jit编译情况,慎用
-XX:+TieredCompilation #启用多层编译,jd8默认开启
-XX:CICompilerCount=4 #编译器数目增加
-XX:-UseBiasedLocking #取消偏向锁
-XX:AutoBoxCacheMax=20000 #自动装箱的缓存数量,如int默认缓存为-128~127
-Djava.security.egd=file:/dev/./urandom #替代默认的/dev/random阻塞生成因子
-XX:+AlwaysPreTouch #启动时访问并置零内存页面,大堆时效果比较好
-XX:-UseCounterDecay #禁止JIT调用计数器衰减。默认情况下,每次GC时会对调用计数器进行砍半的操作,导致有些方法一直是个温热,可能永远都达不到C2编译的1万次的阀值。
-XX:ParallelRefProcEnabled=true # 默认为false,并行的处理Reference对象,如WeakReference
-XX:+DisableExplicitGC #此参数会影响使用堆外内存,会造成oom,如果使用NIO,请慎重开启
#-XX:+UseParNewGC #此参数其实在设置了cms后默认会启用,可以不用设置
-XX:+UseConcMarkSweepGC #使用cms垃圾回收器
#-XX:+UseCMSCompactAtFullCollection #是否在fullgc是做一次压缩以整理碎片,默认启用
-XX:CMSFullGCsBeforeCompaction=0 #full gc触发压缩的次数
#-XX:+CMSClassUnloadingEnabled #如果类加载不频繁,也没有大量使用String.intern方法,不建议打开此参数,况且jdk7后string pool已经移动到了堆中。开启此项的话,即使设置了Xnoclassgc也会进行class的gc, 但是某种情况下会造成bug:https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&cad=rja&uact=8&ved=0ahUKEwjR16Wf6MHQAhWLrVQKHfLdCe4QFgg8MAQ&url=https%3A%2F%2Fblogs.oracle.com%2Fpoonam%2Fentry%2Fjvm_hang_with_cms_collector&usg=AFQjCNFNtkw6jHM-uyz-Wjri3LtAVXWJ8g&sig2=BFxSfHc-AIek18fEhY07mg。
#-XX:+CMSParallelRemarkEnabled #并行标记, 默认开启, 可以不用设置
#-XX:+CMSScavengeBeforeRemark #强制remark之前开始一次minor gc,减少remark的暂停时间,但是在remark之后也将立即开始又一次minor gc
-XX:CMSInitiatingOccupancyFraction=90 #触发full gc的内存使用百分比
-XX:+PrintClassHistogram #打印类统计信息
-XX:+PrintHeapAtGC #打印gc前后的heap信息
-XX:+PrintGCDetails #以下都是为了记录gc日志
-XX:+PrintGCDateStamps
-XX:+PrintGCApplicationStoppedTime #打印清晰的GC停顿时间外,还可以打印其他的停顿时间,比如取消偏向锁,class 被agent redefine,code deoptimization等等
-XX:+PrintTenuringDistribution #打印晋升到老年代的年龄自动调整的情况(并行垃圾回收器启用UseAdaptiveSizePolicy参数的情况下以及其他垃圾回收期也会动态调整,从最开始的MaxTenuringThreshold变成占用当前堆50%的age)
#-XX:+UseAdaptiveSizePolicy # 此参数在并行回收器时是默认开启的会根据应用运行状况做自我调整,如MaxTenuringThreshold、survivor区大小等,其他情况下最好不要开启
#-XX:StringTableSize #字符串常量池表大小(hashtable的buckets的数目),java 6u30之前无法修改固定为1009,后面的版本默认为60013,可以通过此参数设置
-XX:GCTimeLimit=98 #gc占用时间超过多少抛出OutOfMemoryError
-XX:GCHeapFreeLimit=2 #gc回收后小于百分之多少抛出OutOfMemoryError
-Xloggc:/home/logs/gc.log

 

相关文章

Spring boot executable jar/war 原理

$
0
0

Spring boot executable jar/war

spring boot里其实不仅可以直接以 Java -jar demo.jar的方式启动,还可以把jar/war变为一个可以执行的脚本来启动,比如./demo.jar。

把这个executable jar/war 链接到/etc/init.d下面,还可以变为Linux下的一个service。

只要在spring boot maven plugin里配置:

<plugin><groupId>org.springframework.boot</groupId><artifactId>spring-boot-maven-plugin</artifactId><configuration><executable>true</executable></configuration></plugin>

这样子打包出来的jar/war就是可执行的。更多详细的内容可以参考官方的文档。

http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#deployment-install

zip 格式里的 magic number

生成的jar/war实际上是一个zip格式的文件,这个zip格式文件为什么可以在shell下面直接执行?

研究了下zip文件的格式。zip文件是由entry组成的,而每一个entry开头都有一个4个字节的magic number:

Local file header signature = 0x04034b50 (read as a little-endian number)

即 PK\003\004

参考:https://en.wikipedia.org/wiki/Zip_(file_format)

zip处理软件是读取到magic number才开始处理。所以在linux/unix下面,可以把一个bash文件直接写在一个zip文件的开头,这样子会被认为是一个bash script。 而zip处理软件在读取这个文件时,仍然可以正确地处理。

比如spring boot生成的executable jar/war,的开头是:

#!/bin/bash
#
# . ____ _ __ _ _
# /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
# ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
# \\/ ___)| |_)| | | | | || (_| | ) ) ) )
# ' |____| .__|_| |_|_| |_\__, | / / / /
# =========|_|==============|___/=/_/_/_/
# :: Spring Boot Startup Script ::
#

在script内容结尾,可以看到zip entry的magic number:

exit 0
PK^C^D

spring boot 的 launch.script

实际上spring boot maven plugin是把下面这个script打包到fat jar的最前面部分。

https://github.com/spring-projects/spring-boot/blob/1ca9cdabf71f3f972a9c1fdbfe9a9f5fda561287/spring-boot-tools/spring-boot-loader-tools/src/main/resources/org/springframework/boot/loader/tools/launch.script

这个launch.script 支持很多变量设置。还可以自动识别是处于auto还是service不同mode中。

所谓的auto mode就是指直接运行jar/war:

./demo.jar

而service mode则是由操作系统在启动service的情况:

service demo start/stop/restart/status

所以fat jar可以直接在普通的命令行里执行,./xxx.jar 或者link到/etc/init.d/下,变为一个service。

相关文章

Java常见面试题之Forward和Redirect的区别

$
0
0

阅读目录

一:间接请求转发(Redirect)
二:直接请求转发(Forward)

用户向服务器发送了一次HTTP请求,该请求可能会经过多个信息资源处理以后才返回给用户,各个信息资源使用请求转发机制相互转发请求,但是用户是感觉不到请求转发的。根据转发方式的不同,可以区分为直接请求转发(Forward)和间接请求转发(Redirect),那么这两种转发方式有何区别呢?本篇在回答该问题的同时全面的讲解两种请求转发方式的原理和区别。

【出现频率】

☆☆☆☆

【关键考点】

  • 请求转发的含义;
  • Forward转发请求的原理;
  • Redirect转发请求的原理。

【考题分析】

Forward和Redirect代表了两种请求转发方式:直接转发和间接转发。

直接转发方式(Forward),客户端和浏览器只发出一次请求,Servlet、HTML、JSP或其它信息资源,由第二个信息资源响应该请求,在请求对象request中,保存的对象对于每个信息资源是共享的。

间接转发方式(Redirect)实际是两次HTTP请求,服务器端在响应第一次请求的时候,让浏览器再向另外一个URL发出请求,从而达到转发的目的。

举个通俗的例子:

  直接转发就相当于:“A找B借钱,B说没有,B去找C借,借到借不到都会把消息传递给A”;

  间接转发就相当于:”A找B借钱,B说没有,让A去找C借”。

下面详细阐述一下两者的原理:

一:间接请求转发(Redirect)

间接转发方式,有时也叫重定向,它一般用于避免用户的非正常访问。例如:用户在没有登录的情况下访问后台资源,Servlet可以将该HTTP请求重定向到登录页面,让用户登录以后再访问。在Servlet中,通过调用response对象的SendRedirect()方法,告诉浏览器重定向访问指定的URL,示例代码如下: 

......
//Servlet中处理get请求的方法
public void doGet(HttpServletRequest request,HttpServletResponse response){
//请求重定向到另外的资源
    response.sendRedirect("资源的URL");
}
........

上图所示的间接转发请求的过程如下:

  • 浏览器向Servlet1发出访问请求;
  • Servlet1调用sendRedirect()方法,将浏览器重定向到Servlet2;
  • 浏览器向servlet2发出请求;
  • 最终由Servlet2做出响应。

二:直接请求转发(Forward)

直接转发方式用的更多一些,一般说的请求转发指的就是直接转发方式。Web应用程序大多会有一个控制器。由控制器来控制请求应该转发给那个信息资源。然后由这些信息资源处理请求,处理完以后还可能转发给另外的信息资源来返回给用户,这个过程就是经典的MVC模式。

javax.serlvet.RequestDispatcher接口是请求转发器必须实现的接口,由Web容器为Servlet提供实现该接口的对象,通过调用该接口的forward()方法到达请求转发的目的,示例代码如下:

......
    //Servlet里处理get请求的方法
 public void doGet(HttpServletRequest request , HttpServletResponse response){
     //获取请求转发器对象,该转发器的指向通过getRequestDisPatcher()的参数设置
   RequestDispatcher requestDispatcher =request.getRequestDispatcher("资源的URL");
    //调用forward()方法,转发请求      
   requestDispatcher.forward(request,response);    
}
......

上图所示的直接转发请求的过程如下:

  • 浏览器向Servlet1发出访问请求;
  • Servlet1调用forward()方法,在服务器端将请求转发给Servlet2;
  • 最终由Servlet2做出响应。

技巧:其实,通过浏览器就可以观察到服务器端使用了那种请求转发方式,当单击某一个超链接时,浏览器的地址栏会出现当前请求的地址,如果服务器端响应完成以后,发现地址栏的地址变了,则证明是间接的请求转发。相反,如果地址没有发生变化,则代表的是直接请求转发或者没有转发。

问:直接转发和间接转发的原理及区别是什么?

答:Forward和Redirect代表了两种请求转发方式:直接转发和间接转发。对应到代码里,分别是RequestDispatcher类的forward()方法和HttpServletRequest类的sendRedirect()方法。

对于间接方式,服务器端在响应第一次请求的时候,让浏览器再向另外一个URL发出请求,从而达到转发的目的。它本质上是两次HTTP请求,对应两个request对象。

对于直接方式,客户端浏览器只发出一次请求,Servlet把请求转发给Servlet、HTML、JSP或其它信息资源,由第2个信息资源响应该请求,两个信息资源共享同一个request对象。

相关文章

Netty 超时机制及心跳程序实现

$
0
0

本文介绍了 Netty 超时机制的原理,以及如何在连接闲置时发送一个心跳来维持连接。

Netty 超时机制的介绍

Netty 的超时类型 IdleState 主要分为:

  • ALL_IDLE : 一段时间内没有数据接收或者发送
  • READER_IDLE : 一段时间内没有数据接收
  • WRITER_IDLE : 一段时间内没有数据发送

在 Netty 的 timeout 包下,主要类有:

  • IdleStateEvent : 超时的事件
  • IdleStateHandler : 超时状态处理
  • ReadTimeoutHandler : 读超时状态处理
  • WriteTimeoutHandler : 写超时状态处理

其中 IdleStateHandler 包含了读\写超时状态处理,比如

private static final int READ_IDEL_TIME_OUT = 4; // 读超时
private static final int WRITE_IDEL_TIME_OUT = 5;// 写超时
private static final int ALL_IDEL_TIME_OUT = 7; // 所有超时

new IdleStateHandler(READ_IDEL_TIME_OUT,
			WRITE_IDEL_TIME_OUT, ALL_IDEL_TIME_OUT, TimeUnit.SECONDS));

上述例子,在 IdleStateHandler 中定义了读超时的时间是 4 秒, 写超时的时间是 5 秒,其他所有的超时时间是 7 秒。

应用 IdleStateHandler

既然 IdleStateHandler 包括了读\写超时状态处理,那么很多时候 ReadTimeoutHandler 、 WriteTimeoutHandler 都可以不用使用。定义另一个名为 HeartbeatHandlerInitializer 的 ChannelInitializer :

public class HeartbeatHandlerInitializer extends ChannelInitializer<Channel> {

	private static final int READ_IDEL_TIME_OUT = 4; // 读超时
	private static final int WRITE_IDEL_TIME_OUT = 5;// 写超时
	private static final int ALL_IDEL_TIME_OUT = 7; // 所有超时

	@Override
	protected void initChannel(Channel ch) throws Exception {
		ChannelPipeline pipeline = ch.pipeline();
		pipeline.addLast(new IdleStateHandler(READ_IDEL_TIME_OUT,
				WRITE_IDEL_TIME_OUT, ALL_IDEL_TIME_OUT, TimeUnit.SECONDS)); // 1
		pipeline.addLast(new HeartbeatServerHandler()); // 2
	}
}
  1. 使用了 IdleStateHandler ,分别设置了读、写超时的时间
  2. 定义了一个 HeartbeatServerHandler 处理器,用来处理超时时,发送心跳

定义了一个心跳处理器

public class HeartbeatServerHandler extends ChannelInboundHandlerAdapter {

	// Return a unreleasable view on the given ByteBuf
	// which will just ignore release and retain calls.
	private static final ByteBuf HEARTBEAT_SEQUENCE = Unpooled
			.unreleasableBuffer(Unpooled.copiedBuffer("Heartbeat",
					CharsetUtil.UTF_8));  // 1

	@Override
	public void userEventTriggered(ChannelHandlerContext ctx, Object evt)
			throws Exception {

		if (evt instanceof IdleStateEvent) {  // 2
			IdleStateEvent event = (IdleStateEvent) evt;  
			String type = "";
			if (event.state() == IdleState.READER_IDLE) {
				type = "read idle";
			} else if (event.state() == IdleState.WRITER_IDLE) {
				type = "write idle";
			} else if (event.state() == IdleState.ALL_IDLE) {
				type = "all idle";
			}

			ctx.writeAndFlush(HEARTBEAT_SEQUENCE.duplicate()).addListener(
					ChannelFutureListener.CLOSE_ON_FAILURE);  // 3

			System.out.println( ctx.channel().remoteAddress()+"超时类型:" + type);
		} else {
			super.userEventTriggered(ctx, evt);
		}
	}
}
  1. 定义了心跳时,要发送的内容
  2. 判断是否是 IdleStateEvent 事件,是则处理
  3. 将心跳内容发送给客户端

服务器

服务器代码比较简单,启动后侦听 8082 端口

public final class HeartbeatServer {

    static final int PORT = 8082;

    public static void main(String[] args) throws Exception {

        // Configure the server.
        EventLoopGroup bossGroup = new NioEventLoopGroup(1);
        EventLoopGroup workerGroup = new NioEventLoopGroup();
        try {
            ServerBootstrap b = new ServerBootstrap();
            b.group(bossGroup, workerGroup)
             .channel(NioServerSocketChannel.class)
             .option(ChannelOption.SO_BACKLOG, 100)
             .handler(new LoggingHandler(LogLevel.INFO))
             .childHandler(new HeartbeatHandlerInitializer());

            // Start the server.
            ChannelFuture f = b.bind(PORT).sync();

            // Wait until the server socket is closed.
            f.channel().closeFuture().sync();
        } finally {
            // Shut down all event loops to terminate all threads.
            bossGroup.shutdownGracefully();
            workerGroup.shutdownGracefully();
        }
    }
}

客户端测试

客户端用操作系统自带的 Telnet 程序即可:

telnet 127.0.0.1 8082

效果

源码

见 https://github.com/waylau/netty-4-user-guide-demos 中 heartbeat包

参考

  • Netty 4.x 用户指南 https://github.com/waylau/netty-4-user-guide
  • Netty 实战(精髓) https://github.com/waylau/essential-netty-in-action

相关文章


一个轻量级分布式 RPC 框架 — NettyRpc

$
0
0

1、背景

最近在搜索Netty和Zookeeper方面的文章时,看到了这篇文章《 轻量级分布式 RPC 框架》,作者用Zookeeper、Netty和Spring写了一个轻量级的分布式RPC框架。花了一些时间看了下他的代码,写的干净简单,写的RPC框架可以算是一个简易版的 dubbo。这个RPC框架虽小,但是麻雀虽小,五脏俱全,有兴趣的可以学习一下。

本人在这个简易版的RPC上添加了如下特性:

  • 服务异步调用的支持,回调函数callback的支持
  • 客户端使用长连接(在多次调用共享连接)
  • 服务端异步多线程处理RPC请求

项目地址:https://github.com/luxiaoxun/NettyRpc

2、简介

RPC,即 Remote Procedure Call(远程过程调用),调用远程计算机上的服务,就像调用本地服务一样。RPC可以很好的解耦系统,如WebService就是一种基于Http协议的RPC。

这个RPC整体框架如下:

这个RPC框架使用的一些技术所解决的问题:

服务发布与订阅:服务端使用Zookeeper注册服务地址,客户端从Zookeeper获取可用的服务地址。

通信:使用Netty作为通信框架。

Spring:使用Spring配置服务,加载Bean,扫描注解。

动态代理:客户端使用代理模式透明化服务调用。

消息编解码:使用Protostuff序列化和反序列化消息。

3、服务端发布服务

使用注解标注要发布的服务

服务注解

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Component
public @interface RpcService {
    Class<?> value();
}

一个服务接口:

public interface HelloService {

    String hello(String name);

    String hello(Person person);
}

一个服务实现:使用注解标注

@RpcService(HelloService.class)
public class HelloServiceImpl implements HelloService {

    @Override
    public String hello(String name) {
        return "Hello! " + name;
    }

    @Override
    public String hello(Person person) {
        return "Hello! " + person.getFirstName() + " " + person.getLastName();
    }
}

服务在启动的时候扫描得到所有的服务接口及其实现:

@Override
    public void setApplicationContext(ApplicationContext ctx) throws BeansException {
        Map<String, Object> serviceBeanMap = ctx.getBeansWithAnnotation(RpcService.class);
        if (MapUtils.isNotEmpty(serviceBeanMap)) {
            for (Object serviceBean : serviceBeanMap.values()) {
                String interfaceName = serviceBean.getClass().getAnnotation(RpcService.class).value().getName();
                handlerMap.put(interfaceName, serviceBean);
            }
        }
    }

在Zookeeper集群上注册服务地址:

public class ServiceRegistry {

    private static final Logger LOGGER = LoggerFactory.getLogger(ServiceRegistry.class);

    private CountDownLatch latch = new CountDownLatch(1);

    private String registryAddress;

    public ServiceRegistry(String registryAddress) {
        this.registryAddress = registryAddress;
    }

    public void register(String data) {
        if (data != null) {
            ZooKeeper zk = connectServer();
            if (zk != null) {
                AddRootNode(zk); // Add root node if not exist
                createNode(zk, data);
            }
        }
    }

    private ZooKeeper connectServer() {
        ZooKeeper zk = null;
        try {
            zk = new ZooKeeper(registryAddress, Constant.ZK_SESSION_TIMEOUT, new Watcher() {
                @Override
                public void process(WatchedEvent event) {
                    if (event.getState() == Event.KeeperState.SyncConnected) {
                        latch.countDown();
                    }
                }
            });
            latch.await();
        } catch (IOException e) {
            LOGGER.error("", e);
        }
        catch (InterruptedException ex){
            LOGGER.error("", ex);
        }
        return zk;
    }

    private void AddRootNode(ZooKeeper zk){
        try {
            Stat s = zk.exists(Constant.ZK_REGISTRY_PATH, false);
            if (s == null) {
                zk.create(Constant.ZK_REGISTRY_PATH, new byte[0], ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
            }
        } catch (KeeperException e) {
            LOGGER.error(e.toString());
        } catch (InterruptedException e) {
            LOGGER.error(e.toString());
        }
    }

    private void createNode(ZooKeeper zk, String data) {
        try {
            byte[] bytes = data.getBytes();
            String path = zk.create(Constant.ZK_DATA_PATH, bytes, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL);
            LOGGER.debug("create zookeeper node ({} => {})", path, data);
        } catch (KeeperException e) {
            LOGGER.error("", e);
        }
        catch (InterruptedException ex){
            LOGGER.error("", ex);
        }
    }
}

ServiceRegistry

这里在原文的基础上加了AddRootNode()判断服务父节点是否存在,如果不存在则添加一个PERSISTENT的服务父节点,这样虽然启动服务时多了点判断,但是不需要手动命令添加服务父节点了。

关于Zookeeper的使用原理,可以看这里《 ZooKeeper基本原理》。

4、客户端调用服务

使用代理模式调用服务:

public class RpcProxy {

    private String serverAddress;
    private ServiceDiscovery serviceDiscovery;

    public RpcProxy(String serverAddress) {
        this.serverAddress = serverAddress;
    }

    public RpcProxy(ServiceDiscovery serviceDiscovery) {
        this.serviceDiscovery = serviceDiscovery;
    }

    @SuppressWarnings("unchecked")
    public <T> T create(Class<?> interfaceClass) {
        return (T) Proxy.newProxyInstance(
                interfaceClass.getClassLoader(),
                new Class<?>[]{interfaceClass},
                new InvocationHandler() {
                    @Override
                    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
                        RpcRequest request = new RpcRequest();
                        request.setRequestId(UUID.randomUUID().toString());
                        request.setClassName(method.getDeclaringClass().getName());
                        request.setMethodName(method.getName());
                        request.setParameterTypes(method.getParameterTypes());
                        request.setParameters(args);

                        if (serviceDiscovery != null) {
                            serverAddress = serviceDiscovery.discover();
                        }
                        if(serverAddress != null){
                            String[] array = serverAddress.split(":");
                            String host = array[0];
                            int port = Integer.parseInt(array[1]);

                            RpcClient client = new RpcClient(host, port);
                            RpcResponse response = client.send(request);

                            if (response.isError()) {
                                throw new RuntimeException("Response error.",new Throwable(response.getError()));
                            } else {
                                return response.getResult();
                            }
                        }
                        else{
                            throw new RuntimeException("No server address found!");
                        }
                    }
                }
        );
    }
}

这里每次使用代理远程调用服务,从Zookeeper上获取可用的服务地址,通过RpcClient send一个Request,等待该Request的Response返回。这里原文有个比较严重的bug,在原文给出的简单的Test中是很难测出来的,原文使用了obj的wait和notifyAll来等待Response返回,会出现“假死等待”的情况:一个Request发送出去后,在obj.wait()调用之前可能Response就返回了,这时候在channelRead0里已经拿到了Response并且obj.notifyAll()已经在obj.wait()之前调用了,这时候send后再obj.wait()就出现了假死等待,客户端就一直等待在这里。使用CountDownLatch可以解决这个问题。

注意:这里每次调用的send时候才去和服务端建立连接,使用的是短连接,这种短连接在高并发时会有连接数问题,也会影响性能。

从Zookeeper上获取服务地址:

public class ServiceDiscovery {

    private static final Logger LOGGER = LoggerFactory.getLogger(ServiceDiscovery.class);

    private CountDownLatch latch = new CountDownLatch(1);

    private volatile List<String> dataList = new ArrayList<>();

    private String registryAddress;

    public ServiceDiscovery(String registryAddress) {
        this.registryAddress = registryAddress;
        ZooKeeper zk = connectServer();
        if (zk != null) {
            watchNode(zk);
        }
    }

    public String discover() {
        String data = null;
        int size = dataList.size();
        if (size > 0) {
            if (size == 1) {
                data = dataList.get(0);
                LOGGER.debug("using only data: {}", data);
            } else {
                data = dataList.get(ThreadLocalRandom.current().nextInt(size));
                LOGGER.debug("using random data: {}", data);
            }
        }
        return data;
    }

    private ZooKeeper connectServer() {
        ZooKeeper zk = null;
        try {
            zk = new ZooKeeper(registryAddress, Constant.ZK_SESSION_TIMEOUT, new Watcher() {
                @Override
                public void process(WatchedEvent event) {
                    if (event.getState() == Event.KeeperState.SyncConnected) {
                        latch.countDown();
                    }
                }
            });
            latch.await();
        } catch (IOException | InterruptedException e) {
            LOGGER.error("", e);
        }
        return zk;
    }

    private void watchNode(final ZooKeeper zk) {
        try {
            List<String> nodeList = zk.getChildren(Constant.ZK_REGISTRY_PATH, new Watcher() {
                @Override
                public void process(WatchedEvent event) {
                    if (event.getType() == Event.EventType.NodeChildrenChanged) {
                        watchNode(zk);
                    }
                }
            });
            List<String> dataList = new ArrayList<>();
            for (String node : nodeList) {
                byte[] bytes = zk.getData(Constant.ZK_REGISTRY_PATH + "/" + node, false, null);
                dataList.add(new String(bytes));
            }
            LOGGER.debug("node data: {}", dataList);
            this.dataList = dataList;
        } catch (KeeperException | InterruptedException e) {
            LOGGER.error("", e);
        }
    }
}

ServiceDiscovery

每次服务地址节点发生变化,都需要再次watchNode,获取新的服务地址列表。

5、消息编码

请求消息:

public class RpcRequest {

    private String requestId;
    private String className;
    private String methodName;
    private Class<?>[] parameterTypes;
    private Object[] parameters;

    public String getRequestId() {
        return requestId;
    }

    public void setRequestId(String requestId) {
        this.requestId = requestId;
    }

    public String getClassName() {
        return className;
    }

    public void setClassName(String className) {
        this.className = className;
    }

    public String getMethodName() {
        return methodName;
    }

    public void setMethodName(String methodName) {
        this.methodName = methodName;
    }

    public Class<?>[] getParameterTypes() {
        return parameterTypes;
    }

    public void setParameterTypes(Class<?>[] parameterTypes) {
        this.parameterTypes = parameterTypes;
    }

    public Object[] getParameters() {
        return parameters;
    }

    public void setParameters(Object[] parameters) {
        this.parameters = parameters;
    }
}

RpcRequest

响应消息:

public class RpcResponse {

    private String requestId;
    private String error;
    private Object result;

    public boolean isError() {
        return error != null;
    }

    public String getRequestId() {
        return requestId;
    }

    public void setRequestId(String requestId) {
        this.requestId = requestId;
    }

    public String getError() {
        return error;
    }

    public void setError(String error) {
        this.error = error;
    }

    public Object getResult() {
        return result;
    }

    public void setResult(Object result) {
        this.result = result;
    }
}

RpcResponse

消息序列化和反序列化工具:(基于 Protostuff 实现)

public class SerializationUtil {

    private static Map<Class<?>, Schema<?>> cachedSchema = new ConcurrentHashMap<>();

    private static Objenesis objenesis = new ObjenesisStd(true);

    private SerializationUtil() {
    }

    @SuppressWarnings("unchecked")
    private static <T> Schema<T> getSchema(Class<T> cls) {
        Schema<T> schema = (Schema<T>) cachedSchema.get(cls);
        if (schema == null) {
            schema = RuntimeSchema.createFrom(cls);
            if (schema != null) {
                cachedSchema.put(cls, schema);
            }
        }
        return schema;
    }

    /**
     * 序列化(对象 -> 字节数组)
     */
    @SuppressWarnings("unchecked")
    public static <T> byte[] serialize(T obj) {
        Class<T> cls = (Class<T>) obj.getClass();
        LinkedBuffer buffer = LinkedBuffer.allocate(LinkedBuffer.DEFAULT_BUFFER_SIZE);
        try {
            Schema<T> schema = getSchema(cls);
            return ProtostuffIOUtil.toByteArray(obj, schema, buffer);
        } catch (Exception e) {
            throw new IllegalStateException(e.getMessage(), e);
        } finally {
            buffer.clear();
        }
    }

    /**
     * 反序列化(字节数组 -> 对象)
     */
    public static <T> T deserialize(byte[] data, Class<T> cls) {
        try {
            T message = (T) objenesis.newInstance(cls);
            Schema<T> schema = getSchema(cls);
            ProtostuffIOUtil.mergeFrom(data, message, schema);
            return message;
        } catch (Exception e) {
            throw new IllegalStateException(e.getMessage(), e);
        }
    }
}

SerializationUtil

由于处理的是TCP消息,本人加了TCP的粘包处理Handler

channel.pipeline().addLast(new LengthFieldBasedFrameDecoder(65536,0,4,0,0))

消息编解码时开始4个字节表示消息的长度,也就是消息编码的时候,先写消息的长度,再写消息。

6、性能改进

1)服务端请求异步处理

Netty本身就是一个高性能的网络框架,从网络IO方面来说并没有太大的问题。

从这个RPC框架本身来说,在原文的基础上把Server端处理请求的过程改成了多线程异步:

public void channelRead0(final ChannelHandlerContext ctx,final RpcRequest request) throws Exception {
        RpcServer.submit(new Runnable() {
            @Override
            public void run() {
                LOGGER.debug("Receive request " + request.getRequestId());
                RpcResponse response = new RpcResponse();
                response.setRequestId(request.getRequestId());
                try {
                    Object result = handle(request);
                    response.setResult(result);
                } catch (Throwable t) {
                    response.setError(t.toString());
                    LOGGER.error("RPC Server handle request error",t);
                }
                ctx.writeAndFlush(response).addListener(ChannelFutureListener.CLOSE).addListener(new ChannelFutureListener() {
                    @Override
                    public void operationComplete(ChannelFuture channelFuture) throws Exception {
                        LOGGER.debug("Send response for request " + request.getRequestId());
                    }
                });
            }
        });
    }

Netty 4中的Handler处理在IO线程中,如果Handler处理中有耗时的操作(如数据库相关),会让IO线程等待,影响性能。

2)服务端长连接的管理

客户端保持和服务进行长连接,不需要每次调用服务的时候进行连接,长连接的管理(通过Zookeeper获取有效的地址)。

通过监听Zookeeper服务节点值的变化,动态更新客户端和服务端保持的长连接。这个事情现在放在客户端在做,客户端保持了和所有可用服务的长连接,给客户端和服务端都造成了压力,需要解耦这个实现。

3)客户端请求异步处理

客户端请求异步处理的支持,不需要同步等待:发送一个异步请求,返回Feature,通过Feature的callback机制获取结果。

IAsyncObjectProxy client = rpcClient.createAsync(HelloService.class);
RPCFuture helloFuture = client.call("hello", Integer.toString(i));
String result = (String) helloFuture.get(3000, TimeUnit.MILLISECONDS);

个人觉得该RPC的待改进项:

编码序列化的多协议支持。 

项目持续更新中。

项目地址:https://github.com/luxiaoxun/NettyRpc

参考:

  • 轻量级分布式 RPC 框架:http://my.oschina.net/huangyong/blog/361751
  • 你应该知道的RPC原理:http://www.cnblogs.com/LBSer/p/4853234.html

相关文章

Spark Shuffle过程分析:Map阶段处理流程

$
0
0

默认配置情况下,Spark在Shuffle过程中会使用SortShuffleManager来管理Shuffle过程中需要的基本组件,以及对RDD各个Partition数据的计算。我们可以在Driver和Executor对应的SparkEnv对象创建过程中看到对应的配置,如下代码所示:

    // Let the user specify short names for shuffle managers
    val shortShuffleMgrNames = Map("sort" -> classOf[org.apache.spark.shuffle.sort.SortShuffleManager].getName,"tungsten-sort" -> classOf[org.apache.spark.shuffle.sort.SortShuffleManager].getName)
    val shuffleMgrName = conf.get("spark.shuffle.manager", "sort")
    val shuffleMgrClass = shortShuffleMgrNames.getOrElse(shuffleMgrName.toLowerCase, shuffleMgrName)
    val shuffleManager = instantiateClass[ShuffleManager](shuffleMgrClass)

如果需要修改ShuffleManager实现,则只需要修改配置项spark.shuffle.manager即可,默认支持sort和 tungsten-sort,可以指定自己实现的ShuffleManager类。
因为Shuffle过程中需要将Map结果数据输出到文件,所以需要通过注册一个ShuffleHandle来获取到一个ShuffleWriter对象,通过它来控制Map阶段记录数据输出的行为。其中,ShuffleHandle包含了如下基本信息:

  • shuffleId:标识Shuffle过程的唯一ID
  • numMaps:RDD对应的Partitioner指定的Partition的个数,也就是ShuffleMapTask输出的Partition个数
  • dependency:RDD对应的依赖ShuffleDependency

下面我们看下,在SortShuffleManager中是如何注册Shuffle的,代码如下所示:

  override def registerShuffle[K, V, C](
      shuffleId: Int,
      numMaps: Int,
      dependency: ShuffleDependency[K, V, C]): ShuffleHandle = {
    if (SortShuffleWriter.shouldBypassMergeSort(SparkEnv.get.conf, dependency)) {
      new BypassMergeSortShuffleHandle[K, V](
        shuffleId, numMaps, dependency.asInstanceOf[ShuffleDependency[K, V, V]])
    } else if (SortShuffleManager.canUseSerializedShuffle(dependency)) {
      new SerializedShuffleHandle[K, V](
        shuffleId, numMaps, dependency.asInstanceOf[ShuffleDependency[K, V, V]])
    } else {
      new BaseShuffleHandle(shuffleId, numMaps, dependency)
    }
  }

上面代码中,对应如下3种ShuffleHandle可以选择,说明如下:

  • BypassMergeSortShuffleHandle

如果dependency不需要进行Map Side Combine,并且RDD对应的ShuffleDependency中的Partitioner设置的Partition的数量(这个不要和parent RDD的Partition个数混淆,Partitioner指定了map处理结果的Partition个数,每个Partition数据会在Shuffle过程中全部被拉取而拷贝到下游的某个Executor端)小于等于配置参数spark.shuffle.sort.bypassMergeThreshold的值,则会注册BypassMergeSortShuffleHandle。默认情况下,spark.shuffle.sort.bypassMergeThreshold的取值是200,这种情况下会直接将对RDD的 map处理结果的各个Partition数据写入文件,并最后做一个合并处理。

  • SerializedShuffleHandle

如果ShuffleDependency中的Serializer,允许对将要输出数据对象进行排序后,再执行序列化写入到文件,则会选择创建一个SerializedShuffleHandle。

  • BaseShuffleHandle

除了上面两种ShuffleHandle以后,其他情况都会创建一个BaseShuffleHandle对象,它会以反序列化的格式处理Shuffle输出数据。

Map阶段处理流程分析

Map阶段RDD的计算,对应ShuffleMapTask这个实现类,它最终会在每个Executor上启动运行,每个ShuffleMapTask处理RDD的一个Partition的数据。这个过程的核心处理逻辑,代码如下所示:

      val manager = SparkEnv.get.shuffleManager
      writer = manager.getWriter[Any, Any](dep.shuffleHandle, partitionId, context)
      writer.write(rdd.iterator(partition, context).asInstanceOf[Iterator[_ <: Product2[Any, Any]]])

上面代码中,在调用rdd的iterator()方法时,会根据RDD实现类的compute方法指定的处理逻辑对数据进行处理,当然,如果该Partition对应的数据已经处理过并存储在MemoryStore或DiskStore,直接通过BlockManager获取到对应的Block数据,而无需每次需要时重新计算。然后,write()方法会将已经处理过的Partition数据输出到磁盘文件。
在Spark Shuffle过程中,每个ShuffleMapTask会通过配置的ShuffleManager实现类对应的ShuffleManager对象(实际上是在SparkEnv中创建),根据已经注册的ShuffleHandle,获取到对应的ShuffleWriter对象,然后通过ShuffleWriter对象将Partition数据写入内存或文件。所以,接下来我们可能关心每一种ShuffleHandle对应的ShuffleWriter的行为,可以看到SortShuffleManager中获取到ShuffleWriter的实现代码,如下所示:

  /** Get a writer for a given partition. Called on executors by map tasks. */
  override def getWriter[K, V](
      handle: ShuffleHandle,
      mapId: Int,
      context: TaskContext): ShuffleWriter[K, V] = {
    numMapsForShuffle.putIfAbsent(
      handle.shuffleId, handle.asInstanceOf[BaseShuffleHandle[_, _, _]].numMaps)
    val env = SparkEnv.get
    handle match {
      case unsafeShuffleHandle: SerializedShuffleHandle[K @unchecked, V @unchecked] =>
        new UnsafeShuffleWriter(
          env.blockManager,
          shuffleBlockResolver.asInstanceOf[IndexShuffleBlockResolver],
          context.taskMemoryManager(),
          unsafeShuffleHandle,
          mapId,
          context,
          env.conf)
      case bypassMergeSortHandle: BypassMergeSortShuffleHandle[K @unchecked, V @unchecked] =>
        new BypassMergeSortShuffleWriter(
          env.blockManager,
          shuffleBlockResolver.asInstanceOf[IndexShuffleBlockResolver],
          bypassMergeSortHandle,
          mapId,
          context,
          env.conf)
      case other: BaseShuffleHandle[K @unchecked, V @unchecked, _] =>
        new SortShuffleWriter(shuffleBlockResolver, other, mapId, context)
    }
  }

我们以最简单的SortShuffleWriter为例进行分析,在SortShuffleManager可以通过getWriter()方法创建一个SortShuffleWriter对象,然后在ShuffleMapTask中调用SortShuffleWriter对象的write()方法处理Map输出的记录数据,write()方法的处理代码,如下所示:

  /** Write a bunch of records to this task's output */
  override def write(records: Iterator[Product2[K, V]]): Unit = {
    sorter = if (dep.mapSideCombine) {
      require(dep.aggregator.isDefined, "Map-side combine without Aggregator specified!")
      new ExternalSorter[K, V, C](
        context, dep.aggregator, Some(dep.partitioner), dep.keyOrdering, dep.serializer)
    } else {
      // In this case we pass neither an aggregator nor an ordering to the sorter, because we don't
      // care whether the keys get sorted in each partition; that will be done on the reduce side
      // if the operation being run is sortByKey.
      new ExternalSorter[K, V, V](
        context, aggregator = None, Some(dep.partitioner), ordering = None, dep.serializer)
    }
    sorter.insertAll(records)

    // Don't bother including the time to open the merged output file in the shuffle write time,
    // because it just opens a single file, so is typically too fast to measure accurately
    // (see SPARK-3570).
    val output = shuffleBlockResolver.getDataFile(dep.shuffleId, mapId)
    val tmp = Utils.tempFileWith(output)
    val blockId = ShuffleBlockId(dep.shuffleId, mapId, IndexShuffleBlockResolver.NOOP_REDUCE_ID)
    val partitionLengths = sorter.writePartitionedFile(blockId, tmp)
    shuffleBlockResolver.writeIndexFileAndCommit(dep.shuffleId, mapId, partitionLengths, tmp)
    mapStatus = MapStatus(blockManager.shuffleServerId, partitionLengths)
  }

从SortShuffleWriter类中的write()方法可以看到,最终调用了ExeternalSorter的insertAll()方法,实现了Map端RDD某个Partition数据处理并输出到内存或磁盘文件,这也是处理Map阶段输出记录数据最核心、最复杂的过程。我们将其分为两个阶段进行分析:第一阶段是,ExeternalSorter的insertAll()方法处理过程,将记录数据Spill到磁盘文件;第二阶段是,执行完insertAll()方法之后的处理逻辑,创建Shuffle Block数据文件及其索引文件。

内存缓冲写记录数据并Spill到磁盘文件

查看SortShuffleWriter类的write()方法可以看到,在内存中缓存记录数据的数据结构有两种:一种是Buffer,对应的实现类PartitionedPairBuffer,设置mapSideCombine=false时会使用该结构;另一种是Map,对应的实现类是PartitionedAppendOnlyMap,设置mapSideCombine=false时会使用该结构。根据是否指定mapSideCombine选项,分别对应不同的处理流程,我们分别说明如下:

  • 设置mapSideCombine=false时

这种情况在Map阶段不进行Combine操作,在内存中缓存记录数据会使用PartitionedPairBuffer这种数据结构来缓存、排序记录数据,它是一个Append-only Buffer,仅支持向Buffer中追加数据键值对记录,PartitionedPairBuffer的结构如下图所示:
PartitionedPairBuffer
默认情况下,PartitionedPairBuffer初始分配的存储容量为capacity = initialCapacity = 64,实际上这个容量是针对key的容量,因为要存储的是键值对记录数据,所以实际存储键值对的容量为2*initialCapacity = 128。PartitionedPairBuffer是一个能够动态扩充容量的Buffer,内部使用一个一维数组来存储键值对,每次扩容结果为当前Buffer容量的2倍,即2*capacity,最大支持存储2^31-1个键值对记录(1073741823个)。
通过上图可以看到,PartitionedPairBuffer存储的键值对记录数据,键是(partition, key)这样一个Tuple,值是对应的数据value,而且curSize是用来跟踪写入Buffer中的记录的,key在Buffer中的索引位置为2*curSize,value的索引位置为2*curSize+1,可见一个键值对的key和value的存储在PartitionedPairBuffer内部的数组中是相邻的。
使用PartitionedPairBuffer缓存键值对记录数据,通过跟踪实际写入到Buffer内的记录数据的字节数来判断,是否需要将Buffer中的数据Spill到磁盘文件,如下代码所示:

  protected def maybeSpill(collection: C, currentMemory: Long): Boolean = {
    var shouldSpill = false
    if (elementsRead % 32 == 0 && currentMemory >= myMemoryThreshold) {
      // Claim up to double our current memory from the shuffle memory pool
      val amountToRequest = 2 * currentMemory - myMemoryThreshold
      val granted = acquireMemory(amountToRequest)
      myMemoryThreshold += granted
      // If we were granted too little memory to grow further (either tryToAcquire returned 0,
      // or we already had more memory than myMemoryThreshold), spill the current collection
      shouldSpill = currentMemory >= myMemoryThreshold
    }
    shouldSpill = shouldSpill || _elementsRead > numElementsForceSpillThreshold
    // Actually spill
    if (shouldSpill) {
      _spillCount += 1
      logSpillage(currentMemory)
      spill(collection)
      _elementsRead = 0
      _memoryBytesSpilled += currentMemory
      releaseMemory()
    }
    shouldSpill
  }

上面elementsRead表示存储到PartitionedPairBuffer中的记录数,currentMemory是对Buffer中的总记录数据大小(字节数)的估算,myMemoryThreshold通过配置项spark.shuffle.spill.initialMemoryThreshold来进行设置的,默认值为5 * 1024 * 1024 = 5M。当满足条件elementsRead % 32 == 0 && currentMemory >= myMemoryThreshold时,会先尝试向MemoryManager申请2 * currentMemory – myMemoryThreshold大小的内存,如果能够申请到,则不进行Spill操作,而是继续向Buffer中存储数据,否则就会调用spill()方法将Buffer中数据输出到磁盘文件。
向PartitionedPairBuffer中写入记录数据,以及满足条件Spill记录数据到磁盘文件,具体处理流程,如下图所示:
ExternalSorter.insertAllWithoutMapSideCombime
为了查看按照怎样的规则进行排序,我们看一下,当不进行Map Side Combine时,创建ExternalSorter对象的代码如下所示:

      // In this case we pass neither an aggregator nor an ordering to the sorter, because we don't
      // care whether the keys get sorted in each partition; that will be done on the reduce side
      // if the operation being run is sortByKey.
      new ExternalSorter[K, V, V](
        context, aggregator = None, Some(dep.partitioner), ordering = None, dep.serializer)

上面aggregator = None,ordering = None,在对PartitionedPairBuffer中的记录数据Spill到磁盘之前,要使用默认的排序规则进行排序,排序的规则是只对PartitionedPairBuffer中的记录按Partition ID进行升序排序,可以查看WritablePartitionedPairCollection伴生对象类的代码(其中PartitionedPairBuffer类实现了特质WritablePartitionedPairCollection),如下所示:

  /**
   * A comparator for (Int, K) pairs that orders them by only their partition ID.
   */
  def partitionComparator[K]: Comparator[(Int, K)] = new Comparator[(Int, K)] {
    override def compare(a: (Int, K), b: (Int, K)): Int = {
      a._1 - b._1
    }
  }

上面图中,引用了SortShuffleWriter.writeBlockFiles这个子序列图,用来生成Block数据文件和索引文件,后面我们会单独说明。通过对RDD进行计算生成一个记录迭代器对象,通过该迭代器迭代出的记录会存储到PartitionedPairBuffer中,当满足Spill条件时,先对PartitionedPairBuffer中记录进行排序,最后Spill到磁盘文件,这个过程中PartitionedPairBuffer中的记录数据的变化情况,如下图所示:
PartitionedPairBuffer-Sorting-and-Spilling
上图中,对内存中PartitionedPairBuffer中的记录按照Partition ID进行排序,并且属于同一个Partition的数据记录在PartitionedPairBuffer内部的data数组中是连续的。排序结束后,在Spill到磁盘文件时,将对应的Partition ID去掉了,只在文件temp_shuffle_4c4b258d-52e4-47a0-a9b6-692f1af7ec9d中连续存储键值对数据,但同时在另一个内存数组结构中会保存文件中每个Partition拥有的记录数,这样就能根据Partition的记录数来顺序读取文件temp_shuffle_4c4b258d-52e4-47a0-a9b6-692f1af7ec9d中属于同一个Partition的全部记录数据。
ExternalSorter类内部维护了一个SpillFile的ArrayBuffer数组,最终可能会生成多个SpillFile,SpillFile的定义如下所示:

  private[this] case class SpilledFile(
    file: File,
    blockId: BlockId,
    serializerBatchSizes: Array[Long],
    elementsPerPartition: Array[Long])

每个SpillFile包含一个blockId,标识Map输出的该临时文件;serializerBatchSizes表示每次批量写入到文件的Object的数量,默认为10000,由配置项spark.shuffle.spill.batchSize来控制;elementsPerPartition表示每个Partition中的Object的数量。调用ExternalSorter的insertAll()方法,最终可能有如下3种情况:

  • Map阶段输出记录数较少,没有生成SpillFile,那么所有数据都在Buffer中,直接对Buffer中记录排序并输出到文件
  • Map阶段输出记录数较多,生成多个SpillFile,同时Buffer中也有部分记录数据
  • Map阶段输出记录数较多,只生成多个SpillFile

有关后续如何对上面3种情况进行处理,可以想见后面对子序列图SortShuffleWriter.writeBlockFiles的说明。

  • 设置mapSideCombine=true时

这种情况在Map阶段会执行Combine操作,在Map阶段进行Combine操作能够降低Map阶段数据记录的总数,从而降低Shuffle过程中数据的跨网络拷贝传输。这时,RDD对应的ShuffleDependency需要设置一个Aggregator用来执行Combine操作,可以看下Aggregator类声明,代码如下所示:

/**
 * :: DeveloperApi ::
 * A set of functions used to aggregate data.
 *
 * @param createCombiner function to create the initial value of the aggregation.
 * @param mergeValue function to merge a new value into the aggregation result.
 * @param mergeCombiners function to merge outputs from multiple mergeValue function.
 */
@DeveloperApi
case class Aggregator[K, V, C] (
    createCombiner: V => C,
    mergeValue: (C, V) => C,
    mergeCombiners: (C, C) => C) {
  ... ...
}

由于在Map阶段只用到了构造Aggregator的几个函数参数createCombiner、mergeValue、mergeCombiners,我们对这几个函数详细说明如下:

  • createCombiner:进行Aggregation开始时,需要设置初始值。因为在Aggregation过程中使用了类似Map的内存数据结构来管理键值对,每次加入前会先查看Map内存结构中是否存在Key对应的Value,第一次肯定不存在,所以首次将某个Key的Value加入到Map内存结构中时,Key在Map内存结构中第一次有了Value。
  • mergeValue:某个Key已经在Map结构中存在Value,后续某次又遇到相同的Key和一个新的Value,这时需要通过该函数,将旧Value和新Value进行合并,根据Key检索能够得到合并后的新Value。
  • mergeCombiners:一个Map内存结构中Key和Value是由mergeValue生成的,那么在向Map中插入数据,肯定会遇到Map使用容量达到上限,这时需要将记录数据Spill到磁盘文件,那么多个Spill输出的磁盘文件中可能存在同一个Key,这时需要对多个Spill输出的磁盘文件中的Key的多个Value进行合并,这时需要使用mergeCombiners函数进行处理。

该类中定义了combineValuesByKey、combineValuesByKey、combineCombinersByKey,由于这些函数是在Reduce阶段使用的,所以在这里先不说明,后续文章我们会单独详细来分析。
我们通过下面的序列图来描述,需要进行Map Side Combine时的处理流程,如下所示:
ExternalSorter.insertAllWithMapSideCombine
对照上图,我们看一下,当需要进行Map Side Combine时,对应的ExternalSorter类insertAll()方法中的处理逻辑,代码如下所示:

    val shouldCombine = aggregator.isDefined

    if (shouldCombine) {
      // Combine values in-memory first using our AppendOnlyMap
      val mergeValue = aggregator.get.mergeValue
      val createCombiner = aggregator.get.createCombiner
      var kv: Product2[K, V] = null
      val update = (hadValue: Boolean, oldValue: C) => {
        if (hadValue) mergeValue(oldValue, kv._2) else createCombiner(kv._2)
      }
      while (records.hasNext) {
        addElementsRead()
        kv = records.next()
        map.changeValue((getPartition(kv._1), kv._1), update)
        maybeSpillCollection(usingMap = true)
      }
    }

上面代码中,map是内存数据结构,最重要的是update函数和map的changeValue方法(这里的map对应的实现类是PartitionedAppendOnlyMap)。update函数所做的工作,其实就是对createCombiner和mergeValue这两个函数的使用,第一次遇到一个Key调用createCombiner函数处理,非首次遇到同一个Key对应新的Value调用mergeValue函数进行合并处理。map的changeValue方法主要是将Key和Value在map中存储或者进行修改(对出现的同一个Key的多个Value进行合并,并将合并后的新Value替换旧Value)。
PartitionedAppendOnlyMap是一个经过优化的哈希表,它支持向map中追加数据,以及修改Key对应的Value,但是不支持删除某个Key及其对应的Value。它能够支持的存储容量是0.7 * 2 ^ 29 = 375809638。当达到指定存储容量或者指定限制,就会将map中记录数据Spill到磁盘文件,这个过程和前面的类似,不再累述。

创建Shuffle Block数据文件及其索引文件

无论是使用PartitionedPairBuffer,还是使用PartitionedAppendOnlyMap,当需要容量满足Spill条件时,都会将该内存结构(buffer/map)中记录数据Spill到磁盘文件,所以Spill到磁盘文件的格式是相同的。对于后续Block数据文件和索引文件的生成逻辑也是相同,如下图所示:
SortShuffleWriter.writeBlockFiles
假设,我们生成的Shuffle Block文件对应各个参数为:shuffleId=2901,mapId=11825,reduceId=0,这里reduceId是一个NOOP_REDUCE_ID,表示与DiskStore进行磁盘I/O交互操作,而DiskStore期望对应一个(map, reduce)对,但是对于排序的Shuffle输出,通常Reducer拉取数据后只生成一个文件(Reduce文件),所以这里默认reduceId为0。经过上图的处理流程,可以生成一个.data文件,也就是Block数据文件;一个.index文件,也就是包含了各个Partition在数据文件中的偏移位置的索引文件。这个过程生成的文件,示例如下所示:

shuffle_2901_11825_0.data
shuffle_2901_11825_0.index

这样,对于每个RDD的多个Partition进行处理后,都会生成对应的数据文件和索引文件,后续在Reduce端就可以读取这些Block文件,这些记录数据在文件中都是经过分区(Partitioned)的。

Spring Boot异常处理详解

$
0
0

在《 Spring MVC异常处理详解》中,介绍了Spring MVC的异常处理体系,本文将讲解在此基础上Spring Boot为我们做了哪些工作。下图列出了Spring Boot中跟MVC异常处理相关的类。

Spring Boot在启动过程中会根据当前环境进行AutoConfiguration,其中跟MVC错误处理相关的配置内容,在ErrorMvcAutoConfiguration这个类中。以下会分块介绍这个类里面的配置。

在Servlet容器中添加了一个默认的错误页面

因为ErrorMvcAutoConfiguration类实现了EmbeddedServletContainerCustomizer接口,所以可以通过override customize方法来定制Servlet容器。以下代码摘自ErrorMvcAutoConfiguration:

@Value("${error.path:/error}")
private String errorPath = "/error";

@Override
public void customize(ConfigurableEmbeddedServletContainer container) {
    container.addErrorPages(new ErrorPage(this.properties.getServletPrefix()
        + this.errorPath));
}

可以看到ErrorMvcAutoConfiguration在容器中,添加了一个错误页面/error。因为这项配置的存在,如果Spring MVC在处理过程抛出异常到Servlet容器,容器会定向到这个错误页面/error。

那么我们有什么可以配置的呢?

  1. 我们可以配置错误页面的url,/error是默认值,我们可以再application.properties中通过设置error.path的值来配置该页面的url;
  2. 我们可以提供一个自定义的EmbeddedServletContainerCustomizer,添加更多的错误页面,比如对不同的http status code,使用不同的错误处理页面。就像下面这段代码一样:
@Bean
public EmbeddedServletContainerCustomizer containerCustomizer() {
    return new EmbeddedServletContainerCustomizer() {
        @Override
        public void customize(ConfigurableEmbeddedServletContainer container) {
            container.addErrorPages(new ErrorPage(HttpStatus.NOT_FOUND, "/404"));
            container.addErrorPages(new ErrorPage(HttpStatus.INTERNAL_SERVER_ERROR, "/500"));
        }
    };
}

定义了ErrorAttributes接口,并默认配置了一个DefaultErrorAttributes Bean

以下代码摘自ErrorMvcAutoConfiguration:

@Bean
@ConditionalOnMissingBean(value = ErrorAttributes.class, search = SearchStrategy.CURRENT)
public DefaultErrorAttributes errorAttributes() {
    return new DefaultErrorAttributes();
}

以下代码摘自DefaultErrorAttributes, ErrorAttributes, HandlerExceptionResolver:

@Order(Ordered.HIGHEST_PRECEDENCE)
public class DefaultErrorAttributes implements ErrorAttributes, HandlerExceptionResolver,
    Ordered {
    //篇幅原因,忽略类的实现代码。
}

public interface ErrorAttributes {
    public Map<String, Object> getErrorAttributes(RequestAttributes requestAttributes,
        boolean includeStackTrace);
    public Throwable getError(RequestAttributes requestAttributes);
}

public interface HandlerExceptionResolver {
    ModelAndView resolveException(
        HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex);
}

这个DefaultErrorAttributes有什么用呢?主要有两个作用:

  1. 实现了ErrorAttributes接口,具备提供Error Attributes的能力,当处理/error错误页面时,需要从该bean中读取错误信息以供返回;
  2. 实现了HandlerExceptionResolver接口并具有最高优先级,即DispatcherServlet在doDispatch过程中有异常抛出时,先由DefaultErrorAttributes处理。从下面代码中可以发现,DefaultErrorAttributes在处理过程中,是讲ErrorAttributes保存到了request中。事实上,这是DefaultErrorAttributes能够在后面返回Error Attributes的原因,实现HandlerExceptionResolver接口,是DefaultErrorAttributes实现ErrorAttributes接口的手段。
@Override
public ModelAndView resolveException(HttpServletRequest request,
    HttpServletResponse response, Object handler, Exception ex) {
    storeErrorAttributes(request, ex);
    return null;
}

我们有什么可以配置的呢?

我们可以继承DefaultErrorAttributes,修改Error Attributes,比如下面这段代码,去掉了默认存在的error和exception这两个字段,以隐藏敏感信息。

@Bean
public DefaultErrorAttributes errorAttributes() {
    return new DefaultErrorAttributes() {
        @Override
        public Map<String, Object> getErrorAttributes (RequestAttributes requestAttributes,
        boolean includeStackTrace){
            Map<String, Object> errorAttributes = super.getErrorAttributes(requestAttributes, includeStackTrace);
            errorAttributes.remove("error");
            errorAttributes.remove("exception");
            return errorAttributes;
        }
    };
}

我们可以自己实现ErrorAttributes接口,实现自己的Error Attributes方案, 只要配置一个类型为ErrorAttributes的bean,默认的DefaultErrorAttributes就不会被配置。

提供并配置了ErrorController和ErrorView

ErrorController和ErrorView提供了对错误页面/error的支持。ErrorMvcAutoConfiguration默认配置了BasicErrorController和WhiteLabelErrorView,以下代码摘自ErrorMvcAutoConfiguration:

@Bean
@ConditionalOnMissingBean(value = ErrorController.class, search = SearchStrategy.CURRENT)
public BasicErrorController basicErrorController(ErrorAttributes errorAttributes) {
    return new BasicErrorController(errorAttributes);
}

@Configuration
@ConditionalOnProperty(prefix = "error.whitelabel", name = "enabled", matchIfMissing = true)
@Conditional(ErrorTemplateMissingCondition.class)
protected static class WhitelabelErrorViewConfiguration {
    private final SpelView defaultErrorView = new SpelView("<html><body><h1>Whitelabel Error Page</h1>"
                    + "<p>This application has no explicit mapping for /error, so you are seeing this as a fallback.</p>"
                    + "<div id='created'>${timestamp}</div>"
                    + "<div>There was an unexpected error (type=${error}, status=${status}).</div>"
                    + "<div>${message}</div></body></html>");

    @Bean(name = "error")
    @ConditionalOnMissingBean(name = "error")
    public View defaultErrorView() {
        return this.defaultErrorView;
    }

    // If the user adds @EnableWebMvc then the bean name view resolver from
    // WebMvcAutoConfiguration disappears, so add it back in to avoid disappointment.
    @Bean
    @ConditionalOnMissingBean(BeanNameViewResolver.class)
    public BeanNameViewResolver beanNameViewResolver() {
        BeanNameViewResolver resolver = new BeanNameViewResolver();
        resolver.setOrder(Ordered.LOWEST_PRECEDENCE - 10);
        return resolver;
    }
}

ErrorController根据Accept头的内容,输出不同格式的错误响应。比如针对浏览器的请求生成html页面,针对其它请求生成json格式的返回。代码如下:

@RequestMapping(value = "${error.path:/error}", produces = "text/html")
public ModelAndView errorHtml(HttpServletRequest request) {
    return new ModelAndView("error", getErrorAttributes(request, false));
}

@RequestMapping(value = "${error.path:/error}")
@ResponseBody
public ResponseEntity<Map<String, Object>> error(HttpServletRequest request) {
    Map<String, Object> body = getErrorAttributes(request, getTraceParameter(request));
    HttpStatus status = getStatus(request);
    return new ResponseEntity<Map<String, Object>>(body, status);
}

WhitelabelErrorView则提供了一个默认的白板错误页面。

我们有什么可以配置的呢?

  1. 我们可以提供自己的名字为error的view,以替换掉默认的白板页面,提供自己想要的样式。
  2. 我们可以继承BasicErrorController或者干脆自己实现ErrorController接口,用来响应/error这个错误页面请求,可以提供更多类型的错误格式等。

总结

Spring Boot提供了默认的统一错误页面,这是Spring MVC没有提供的。在理解了Spring Boot提供的错误处理相关内容之后,我们可以方便的定义自己的错误返回的格式和内容。不过,如果要实现统一的REST API接口的出错响应,就如这篇文章里的这样,还是要做不少工作的。

相关文章

自建一个电话呼叫中心要多少钱?

$
0
0

我十分看不惯任何行业的潜规则行为。自建一个电话呼叫中心的报价是多少钱?没有人敢公开报价。我明说吧,自建一个电话呼叫中心,只需要3万元左右,而且还能更省钱。

这个报价是针对小型企业的,也就是广大人民群众。至于大型企业,它们自己去定制,钱不是问题。

3万元建一个电话呼叫中心,包括什么?包括硬件设备,软件。软件是硬件设备上免费赠送的,不要钱!有了这个呼叫中心,你可以有语音导航功能(也就是按0转人工客服),还有人工客服排队,电话录音。够用了,中小企业没那么多花哨的需求。

其它的什么狗屁工单,CRM,根本没人用,没这个需求,不会有人愿意付费的。这年头,开发一个工单系统CRM系统根本就是几块钱的事,再说,现在的公司哪个没有自己的CRM工作流?没有人愿意为这些鸡肋功能付费,所以很多厂商逮着一个人就漫天报价,10万,20万,100万!就想着坑到一个是一个。

Related posts:

  1. 音频编码的一些笔记
  2. SIP tag 和 Call-ID 的区别
  3. SIP报文Via和Contact的区别
  4. 让他们来告我吧!
  5. 史上最强大的PHP Web面试题(会做就能进百度)

【译】Reddit如何统计每个帖子的浏览量

$
0
0

之前没听过也没了解过 HyperLogLog,通过翻译这篇文章正好简单学习下。欢迎指正错误~

我们想要更好的向用户展示 Reddit 的规模。为了这一点,投票和评论数是一个帖子最重要的指标。然而,在 Reddit 上有相当多的用户只浏览内容,既不投票也不评论。所以我们想要建立一个能够计算一个帖子浏览数的系统。这一数字会被展示给帖子的创作者和版主,以便他们更好的了解某个帖子的活跃程度。

在这篇博客中,我们将讨论我们是如何实现超大数据量的计数。

计数机制

对于计数系统我们主要有四种需求:

  • 帖子浏览数必须是实时或者近实时的,而不是每天或者每小时汇总。
  • 同一用户在短时间内多次访问帖子,只算一个浏览量
  • 显示的浏览量与真实浏览量间允许有小百分之几的误差
  • Reddit 是全球访问量第八的网站,系统要能在生产环境的规模上正常运行,仅允许几秒的延迟

要全部满足以上四个需求的困难远远比听上去大的多。为了实时精准计数,我们需要知道某个用户是否曾经访问过这篇帖子。想要知道这个信息,我们就要为每篇帖子维护一个访问用户的集合,然后在每次计算浏览量时检查集合。一个 naive 的实现方式就是将访问用户的集合存储在内存的 hashMap 中,以帖子 Id 为 key。

这种实现方式对于访问量低的帖子是可行的,但一旦一个帖子变得流行,访问量剧增时就很难控制了。甚至有的帖子有超过 100 万的独立访客! 对于这样的帖子,存储独立访客的 ID 并且频繁查询某个用户是否之前曾访问过会给内存和 CPU 造成很大的负担。

因为我们不能提供准确的计数,我们查看了几种不同的基数估计算法。有两个符合我们需求的选择:

  • 一是线性概率计数法,很准确,但当计数集合变大时所需内存会线性变大。
  • 二是基于 HyperLogLog (以下简称 HLL )的计数法。 HLL 空间复杂度较低,但是精确度不如线性计数。

下面看下 HLL 会节省多少内存。如果我们需要存储 100 万个独立访客的 ID, 每个用户 ID 8 字节长,那么为了存储一篇帖子的独立访客我们就需要 8 M的内存。反之,如果采用 HLL 会显著减少内存占用。不同的 HLL 实现方式消耗的内存不同。如果采用这篇文章的实现方法,那么存储 100 万个 ID 仅需 12 KB,是原来的 0.15%!!

Big Data Counting: How to count a billion distinct objects using only 1.5KB of Memory – High Scalability -这篇文章很好的总结了上面的算法。

许多 HLL 的实现都是结合了上面两种算法。在集合小的时候采用线性计数,当集合大小到达一定的阈值后切换到 HLL。前者通常被成为 ”稀疏“(sparse) HLL,后者被称为”稠密“(dense) HLL。这种结合了两种算法的实现有很大的好处,因为它对于小集合和大集合都能够保证精确度,同时保证了适度的内存增长。可以在 google 的 这篇论文中了解这种实现的详细内容。

现在我们已经确定要采用 HLL 算法了,不过在选择具体的实现时,我们考虑了以下三种不同的实现。因为我们的数据工程团队使用 Java 和 Scala,所以我们只考虑 Java 和 Scala 的实现。

  • Twitter 提供的 Algebird,采用 Scala 实现。Algebird 有很好的文档,但他们对于 sparse 和 dense HLL 的实现细节不是很容易理解。
  • stream-lib中提供的 HyperLogLog++, 采用 Java 实现。stream-lib 中的代码文档齐全,但有些难理解如何合适的使用并且改造的符合我们的需求。
  • Redis HLL 实现,这是我们最终选择的。我们认为 Redis 中 HLLs 的实现文档齐全、容易配置,提供的相关 API 也很容易集成。还有一个好处是,我们可以用一台专门的服务器部署,从而减轻性能上的压力。

Reddit 的数据管道依赖于 Kafka。当一个用户访问了一篇博客,会触发一个事件,事件会被发送到事件收集服务器,并被持久化在 Kafka 中。

之后,计数系统会依次顺序运行两个组件。在我们的计数系统架构中,第一部分是一个 Kafka 的消费者,我们称之为 Nazar。Nazar 会从 Kafka 中读取每个事件,并将它通过一系列配置的规则来判断该事件是否需要被计数。我们取这个名字仅仅是因为 Nazar 是一个眼睛形状的护身符,而 ”Nazar“ 系统就像眼睛一样使我们的计数系统远离不怀好意者的破坏。其中一个我们不将一个事件计算在内的原因就是同一个用户在很短时间内重复访问。Nazar 会修改事件,加上个标明是否应该被计数的布尔标识,并将事件重新放入 Kafka。

下面就到了系统的第二个部分。我们将第二个 Kafka 的消费者称作 Abacus,用来进行真正浏览量的计算,并且将计算结果显示在网站或客户端。Abacus 从 Kafka 中读取经过 Nazar 处理过的事件,并根据 Nazar 的处理结果决定是跳过这个事件还是将其加入计数。如果 Nazar 中的处理结果是可以加入计数,那么 Abacus 首先会检查这个事件所关联的帖子在 Redis 中是否已经存在了一个 HLL 计数器。如果已经存在,Abacus 会给 Redis 发送个 PFADD 的请求。如果不存在,那么 Abacus 会给 Cassandra 集群发送个请求(Cassandra 用来持久化 HLL 计数器和 计数值的),然后向 Redis 发送 SET 请求。这通常会发生在网友访问较老帖子的时候,这时该帖子的计数器很可能已经在 Redis 中过期了。

为了存储存在 Redis 中的计数器过期的老帖子的浏览量。Abacus 会周期性的将 Redis 中全部的 HLL 和 每篇帖子的浏览量写入到 Cassandra 集群中。为了避免集群过载,我们以 10 秒为周期批量写入。

下图是事件流的大致流程:

总结

我们希望浏览量可以让发帖者了解帖子全部的访问量,也帮助版主快速定位自己社区中高访问量的帖子。在未来,我们计划利用我们数据管道在实时方面的潜力来为 Reddit 的用户提供更多的有用的反馈。

可能感兴趣的文章

谈一下我们是如何开展code review的

$
0
0

众所周知,代码审查是软件开发过程中十分重要的环节,楼主结合自己的实际工作经验,和大家分享一下在实际工作中代码审查是如何开展的。

笔者水平有限,若有错误和纰漏,还请大家指正。

代码审查的阻力

我想不通公司不同部门对代码审查这项工作的重视程度还是不一样的,对于代码审查的阻力总结了以下几点:

  • 国内的整体环境,国内的公司,尤其是互联网公司,讲究速度致上,软件开发的迭代周期周期短,速度快,因为竞争太大,开发的产品要求快速上线,对代码审查不是很重视,先上线,出了问题再解决。
  • 公司的规模,大公司重视流程,把代码审查作为软件开发中的重要一环,甚至计入考核,不管什么一旦成为制度,开展起来就相对容易了。小公司则不然,尤其是刚起步的,可能觉的代码审查没有必要。
  • 和你的领导有关系,就和上面说的,代码审查如果没有形成制度,如果你的领导是技术出身,明白代码审查的重要性,那么会要求你去做。如果是来自别的领域,可能认识不到它的重要性,觉的代码审查是浪费时间(就和代码重构一个道理)。
  • 个人原因,尤其是刚刚进入公司的员工,大学的软件工程课里面好像是没有介绍代码审查的,就是有,没有实际经验,也体会不到它的重要性,笔者刚入职时就是这么认为的。

代码审查的重要性

说了代码审查工作的开展遇到的阻力,下面说一下为什么代码审查是重要的。

  • 代码审查是保证代码质量的重要手段。软件缺陷可能隐藏在各个地方,测试是发现缺陷的重要方法,但专业的测试人员更多的可能是黑盒测试,他们不去关注代码内部的逻辑,只去关注代码实现的功能,有人说测试代码中的逻辑需要开发人员进行单元测试,一方面,单元测试覆盖率基本上不可能达到100%,另一方面,毕竟是单元测试,测试场景简单,有些复杂的场景有可能会测不到。各种测试完成后,如果还有缺陷,那只能让客户充当我们的“终极测试”了。抱怨会接踵而来,客户满意度会越来越低。所以,我们要想出一切可以使用的方法来进一步提高代码质量的方法,还有代码审查么,测试发现不了的问题,通过代码审查也许你能够发现。
  • 代码审查是熟悉软件架构,了解软件业务逻辑的好方法。学习代码是需要切入点的,一个上百万行代码的系统,从哪里开始着手,只能一个模块一个模块,一个组件一个组件的来熟悉,掌握。实现一个比较大的功能,你应该不会是唯一的开发人员,从系统架构师输出的系统设计,然后到各个团队中技术Lead输出的component级别的设计,到开始实现时,应该会把功能分为不同的模块有不同的开发人员协同实现。这是个学习的机会,不要只局限于自己这部分,为了了解这个大的功能,甚至和这个功能相关的其他已经实现的功能,你同样需要关注其他人的工作。有目的的看代码和漫无目的的浏览效果是不一样的,你已经对新功能有所了解,审查代码之前,你认为代码会怎么写,别人哪里和你想的不一样,旧功能和新功能是如何相互影响的等等,心里怀着问题,你的学习速度会更快,记得更加深刻。
  • 代码审查是你提高自己的好方法。前提是team中有经验丰富的开发人员的存在。也就是大牛,不要错过让他看你代码的机会,不要害怕他会为你写的代码挑出一大堆问题,有人说你自己写的代码就像自己的孩子,见不得别人说半点不字,不要固执,要内心平静的,客观的去看待你所写的代码,发现并解决问题才能提高你自己。也不要错过去review大牛代码的机会,看看大牛写出来的代码是怎样的,你可以取其精华。
  • 代码审查是需要功力的。网上有帖子说程序员的资深与否和工作年限没有必然联系,你是5年工作经验还是一个经验用了5年,这需要你去刻意练习,刚开始reveiew代码的时候你可能不习惯,也可能很痛苦,面对的一屏幕的代码不知如何下眼。但有一句话,如果你觉的内心很舒服,你就是在原地踏步。觉的痛苦说明你是在爬坡,刻意的去联系自己的大脑吧,今天你看一页代码可能用了一个小时,没有发现问题,但是坚持一个月甚至三个月之后,你看一眼就能够发现代码中的缺陷,恭喜你,你的功力加深了。

我们是如何开展代码审查的

好了。罗嗦了半天。下面开始说一下在楼主参与的项目中是如果开展code review的。

第一家公司,是一家国内的大公司,就不说名字了,我所在的部门开发的产品众多,换项目很频繁,我参与的有3,4个吧,开发流程不规范,部门老大没有对代码审查有硬性要求。但带我的老师,也是项目经理(但是主要做技术,所以也可以说是技术经理)是一个非常热衷于技术的人,应该说明白代码review的重要性,我们敏捷团队有4个开发,每次写完代码后,都会进行team review。把代码投到大屏幕上,然后老师带我们去review代码。印象深刻的一次是一个同事着急回家过年,草草把代码就提交走人了,被师傅挑出来很多问题。换了项目和项目经理之后,代码review就不了了之了。

第二家公司,是一个外企,有几十年的历史了,开发流程算是比较规范了,而且分工明确。在这家公司我们的大老板(也就是技术经理的上司)对代码review是有要求的,下面详细说明我们的代码审查是如何一步一步演进的。

  • 第一阶段   team review + TFVC

先简单介绍下我们的版本控制工具:微软的TFVC,代码的branch是按如下图创建的,有一个main branch每个scrum team一个branch,出release之前把各个team的branch merge回main,最后出release branch,release branch上修复的bug也要最终回main。

开始的时候我们是没有peer review的,每两周开一次team review。一个主持人,负责预定会议室,操作visual studio查看最近两周提交的changeset,一个记录员,负责记录发现的问题,相关功能的开发人员负责讲解和解答疑问。最后记录员将review结果记录到wiki中并发送到整个开发部门。

  • 第二阶段 自律TFVC + peer review + team review

记不太清是从哪个visual studio版本开始支持code review了,好像是VS2012。在提交之前每个开发人员需要将代码提交给至少一个人进行review,然后生成一个code review的work item。你需要将这个work item链接到你的changeset中才能check in代码,不然我们公司自定义的policy会发出警告。这些警告是可以被忽略的,然后也能强制提交。前面说过部分老大对code review是很重视的,如何才能检查peer review的结果呢?对,将这些code review的work item数据进行查询,将没有链接work item的changeset过滤出来,然后将结果显示。技术经理和老大一眼就能看到谁没有遵守这个流程。尽管这么做了,开始执行的时候还是有不少的人出现在查询结果中。

说一下自律的问题,公司添加这个查询review结果的措施是手段,只是在某种程度上保证了流程,但目的是什么?目的是需要收到review请求的成员认认真真的review代码,而不是随便的走一下流程就OK。如果你认识到review的重要性,你可能会用心一点吧。

我们的team review 会议依然在进行,和peer review的区别就是peer review只给一个人或者少数的人进行review,而team review 是在整个scrum team间进行。

  • 第三阶段 GIT + peer review + team review

我们的公司虽然历史悠久,但对一些流程的工具和技术还是极力推崇的。大家都知道GIT是非常流行的版本控制工具,visual studio 2012也开始支持GIT,我们也一步一步的 将source code移到了TFS-GIT中。

和TFVC相比,GIT的branch是非常轻量级的,你可以很容易并且快速的创建一个branch。所以我们现在可以将branch进行细分了。TFVC和GIT的代码提交也不一样,TFVC是集中式的,最全的代码放在server上,你需要一个branch的code时要将其check out到本地。每次提交都是把代码从local一次性merge到server,如果出现conflicts,你需要在本地处理然后check in。GIT是分布式的,每个人clone的时候都会把所有分支download到本地,代码提交是通过pull request来进行的,也就是通过branch之间的merge来进行,这一点刚从TFVC转到GIT的时候很难理解。这样就得为每个人创建一个临时branch,注意这个branch在本地和server端同时存在,我们用这个branch开发自己的代码并用这个branch进行merge code。这里的pull request就相当于TFVC中的code review,TFVC你还可以偷懒忽略code review的work item,在这里就是强制性的了,没有pull request,别人不会approve你的代码,你根本就没有方法将你的代码merge到feature branch中。

还有team review会议也是照常进行的。

谈一下我们是如何开展code review的,首发于 文章 - 伯乐在线

实现前后端分离的心得

$
0
0

实现前后端分离的心得

对目前的web来说,前后端分离已经变得越来越流行了,越来越多的企业/网站都开始往这个方向靠拢。那么,为什么要选择前后端分离呢?前后端分离对实际开发有什么好处呢?

为什么选择前后端分离

  • 在以前传统的网站开发中,前端一般扮演的只是切图的工作,只是简单地将UI设计师提供的原型图实现成静态的HTML页面,而具体的页面交互逻辑,比如与后台的数据交互工作等,可能都是由后台的开发人员来实现的,或者是前端是紧紧的耦合后台。比如,以前淘宝的Web基本上都是基于MVC框架webx,架构决定了前端只能依赖后端。所以他们的开发模式依然是,前端写好静态demo,后端翻译成VM模版,这种模式的问题就不说了,被吐槽了很久。
  • 而且更有可能后台人员直接兼顾前端的工作,一边实现API接口,一边开发页面,两者互相切换着做,而且根据不同的url动态拼接页面,这也导致后台的开发压力大大增加。前后端工作分配不均。不仅仅开发效率慢,而且代码难以维护。而前后端分离的话,则可以很好的解决前后端分工不均的问题,将更多的交互逻辑分配给前端来处理,而后端则可以专注于其本职工作,比如提供API接口,进行权限控制以及进行运算工作。而前端开发人员则可以利用nodejs来搭建自己的本地服务器,直接在本地开发,然后通过一些插件来将api请求转发到后台,这样就可以完全模拟线上的场景,并且与后台解耦。前端可以独立完成与用户交互的整一个过程,两者都可以同时开工,不互相依赖,开发效率更快,而且分工比较均衡。

如何做到前后端分离

(以下的内容都是基于我们的电影购票网站来讨论的)
前端的技术框架是: vue全家桶+nodejs+express(实现的是单页面(SPA)应用)
首先,先分清楚前后端的工作

  • 前端的工作:实现整一个前端页面以及交互逻辑,以及利用ajax与nodejs服务器(中间层)交互
  • 后端的工作:提供API接口,利用redis来管理session,与数据库交互

我们项目的整一个架构如下:

这里写图片描述

接下来进入正题,如何实现前后端分离

  1. 一般来说,要实现前后端分离,前端就需要开启一个本地的服务器来运行自己的前端代码,以此来模拟真实的线上环境,并且,也是为了更好的开发。因为你在实际开发中,你不可能要求每一个前端都去搭建一个java(php)环境,并且在java环境下开发,这对于前端来说,学习成本太高了。但如果本地没有开启服务器的话,不仅无法模拟线上的环境,而且还面临到了跨域的问题,因为你如果写静态的html页面,直接在文件目录下打开的话,你是无法发出ajax请求的(浏览器跨域的限制),因此,你需要在本地运行一个服务器,可是又不想搭建陌生而庞大的java环境,怎么办法呢?nodejs正好解决了这个问题。在我们项目中,我们利用nodejs的express框架来开启一个本地的服务器,然后利用nodejs的一个http-proxy-middleware插件将客户端发往nodejs的请求转发给真正的服务器,让nodejs作为一个中间层。这样,前端就可以无忧无虑的开发了
  2. 由于前后端分离后,前端和后台同时开发时,就可能遇到前端已经开发好一个页面了,可是却等待后台API接口的情况。比如说A是负责前端,B是负责后台,A可能用了一周做好了基本的结构,并且需要API接口联调后,才能继续开发,而此时B却还没有实现好所需要的接口,这种情况,怎么办呢?在我们这个项目里,我们是通过了mock来提供一些假数据,我们先规定好了API接口,设计出了一套API文档,然后我们就可以通过API文档,利用mock( http://mockjs.com)来返回一些假数据,这样就可以模拟发送API到接受响应的整一个过程,因此前端也不需要依赖于后端开发了,可以独立开发,等到后台的API全部设计完之后,就可以比较快速的联调

为什么要引入nodejs作为中间层

前面的我发的项目结构图中,已经表明,在这个项目里,我们将nodejs作为中间层,那么,为什么我们要特地引入nodejs呢?直接用java做不就行了吗?

  • 我觉得引入nodejs主要是为了分层开发,职责划分,nodejs作为前端服务器,由前端开发人员负责,前端开发人员不需要知道java后台是如何实现的,也不需要知道API接口是如何实现的,我们只需要关心我们前端的开发工作,并且管理好nodejs前端服务器,而后台开发人员也不需要考虑如何前端是如何部署的,他只需要做好自己擅长的部分,提供好API接口就可以;
  • nodejs本身有着独特的异步、非阻塞I/O的特点,这也就意味着他特别适合I/O密集型操作,在处理并发量比较大的请求上能力比较强,因此,利用它来充当前端服务器,向客户端提供静态文件以及响应客户端的请求,我觉得这是一个很不错的选择。

前端服务器如何部署

nodejs前端服务器的职责

  1. 作为静态文件服务器,当用户访问网站的时候,将index.html以及其引入的js、css、fonts以及图片返回给用户
  2. 负责将客户端发来的ajax请求转发给后台服务器

其实前端服务器的部署工作是算比较简单的,具体有以下两个点:

  1. 将开发完的前端代码,利用webpack打包成静态压缩文件
  2. 在服务器上,利用pm2负载均衡器来执行以下的代码来开启服务器:

评论区有人提到有一个不错的文章,我看了下觉得写得确实很详细,大家也可能看一下: https://segmentfault.com/a/1190000009329474?_ea=2038402 (感觉这就是业务与专业的区别哈哈)
(PS:其实也有一个做法,就是用nginx来做反向代理,负责转发请求,根据客户端访问的url把这个请求转发到不同的服务,比如访问/api/*的请求,就转发到后台服务,访问其它的请求,就转发到nodejs服务)
以上,就是我对于前后端分离的一些看法,以及一些实践,如果大家有什么好的想法,欢迎交流。

本次项目代码的地址为: https://github.com/chenjigeng/filmshopping

实现前后端分离的心得,首发于 文章 - 伯乐在线


欢迎来到后 ASO 时代

$
0
0

6 月 WWDC 上所宣布的「App Store 将迎来大改版」的消息,给 ASO 界砸下了一枚重磅炸弹。虽说 iOS11 要到今年秋季才会正式推送,且正式版面世到大面积使用还需要一定时间,到底会不会迎来一个新的 ASO 时代,目前尚不可知。

为了做好迎接新时代的准备,咱们先来看看苹果砸下的到底是一枚什么样的「炸弹」。

搜索改动还算小

「搜索」入口所带来的可观流量,是我们「做关键词」的立足点。ASOer 的主要工作之一就是,做到当用户搜索相关关键词的时候,我们的 应用会出现在搜索结果中且排名前列

到了 iOS11 之后搜索将会发生哪些变化呢?我们就按照「搜索 -> 应用详情 -> 下载」这条路径来看看。

  1. 搜索入口
    •  搜索入口从右二被挪到到右一的位置
    • 热搜词从 10 个降为 7 个

    虽然官方从未公开过热搜词的筛选算法,但根据长期观察,我们发现 热搜词会受到搜索频次、短期下载次数、社会化分享、用户评分评论和苹果人为干涉等影响

    可以发现除了苹果人为干涉之外,其他几个影响热搜词的因素都是可控的,所以刷榜或是积分墙依然有存在意义,也将无法杜绝。

  2. 搜索结果
    • 应用名不折行,「副标题」可能显示不全
    • 应用名下方默认展示应用所在的次分类(是的每个应用可以设置主分类和次分类)
    • 应用截图展示三张,应用视频可以展示三个

    目前,为了扩张词库、增加关键词权重,我们所谓的副标题其实是在「应用名称」的位置,用连字符与应用名区分开。从本质上来说“企鹅FM-做电台直播, 听有声书情感音乐广播剧”应该都是算作「应用名称」。 在新版搜索结果中设置过副标题的应用名基本显示不全

    还好,此次大改版 新增了“subtitle”字段(注:后文均用 subtitle 表示苹果规定的副标题,以区分人为设置的副标题),也就是 App Store 的「亲生副标题」。如果设置了,它会出现在应用名称下方,也就是上图中应用次分类的位置。subtitle 对于关键词收录和用户查看应用详情页的可能性都会有影响。它似乎和安卓平台上的一句话简介有了相似的作用。

    应用截图二变三、视频一变三,换言之,搜索结果中能传达给用户的信息更多了。听起来是个好事,但多不一定是好,也可能是一个坑。虽然系统升级了,但多数用户的硬件并没有升级,要在 iPhone6 或者 iPhone7 的屏幕上多塞入一张截图,就需要运营和视觉把控好传达的信息。画布没有变大,但能承载的信息变多了,也可以算是一种诱惑吧。

  3. 应用详情页
    • 自然,应用名称显示完整。应用名下方默认显示次分类,有 subtitle 则显示 subtitle
    • What’s new 被放到了第一屏,默认显示前三行
    • 应用详情、评分评论和相关应用依次排列在应用截图之后,相关应用推荐甚至到了最后一屏

    值得注意的是,原来被排在描述之后的 What’s new ,在大改版中突然翻身做主,坐到了黄金位置,虽然不知道官方的意图,但这无疑又是一块可运营的空间,值得思考如何将它变成一个拉新工具。

    其实评分在 What’s new 上方也有,但是用户评论是在第二屏位置。笔者对于描述和用户评论无甚想法,但对被放到了最后一屏的相关应用推荐,就略有担忧。毕竟通过友链还是能引一部分流量的,现在位置被调整到了犄角旮旯,来自于此的流量多少将会受到影响。

 

榜单 Jobs 估计都不认识了

榜单改动虽大,但影响不及搜索。假如幸运地被推荐,很是可以捧着当日新增笑了。

  1. tab 换血
    • 「今天」取代「精品推荐」
    • 「游戏」成为与 APP 同级的入口
    • 「类别」和「排行榜」不再是一级入口

    值得一说的是,「游戏」被升级为一个单独的 tab。笔者认为这可能是苹果在平衡 App Store 的公平性和调整营收力度:其他互联网产品的流量和游戏的流量都不在一个量级上,而游戏 App 所带来的营收也不是其他产品可以拍马追上的。

  2. 每日更新的「今天」
    • 卡片式设计风格
    • 庞大的人工编辑团队
    • 从原来每周更新到每日更新

    目前公认的未来最大流量入口就是「今天」,除了推荐 App 之外,还有专题、文章……这不仅仅是一个卖应用更新应用的杂货铺,是要发展成能看电影吃饭的购物商场,将用户更长久地留在 App Store 中。业界对于上推荐位的普遍看法是,如果 应用中使用到苹果主推的新技术(比如 AR)或者新 API,那么上推荐位的几率将大大提高

  3. 收归了「类别」和「排行榜」的 「APP」
    • 取消「畅销榜」
    • 「付费榜」、「免费榜」和「类别」依次在倒数第二屏到最后一屏的位置
    • 「付费榜」和「免费榜」默认展示前三位,可左右滑动或点右上角「查看全部」查看榜单

    传言取消畅销榜是因为刷榜太多,规则玩崩了,所以苹果直接取消畅销榜让刷榜没得玩。不过这个事情…笔者认为刷榜公司还是能够找到对策的。

    对于不刷榜的我们受到更大影响的可能是「类别」的移动,这一举动相当于从一级入口到了三级入口(毕竟是最后一屏)。来自分类的流量将会受到一定影响,所以更要通过把握搜索来挽回损失的流量。

 

其他

除新增的 subtitle 字段之外,App Store 还新增了「宣传文本」字段,限制 170 字, 可以随时更改不需要审核。成功提交后,这段文字会出现在应用描述之上,应用截图之下,大概第二屏的位置。通常应用截图在第一屏是无法显示完整的,用户大概率上会看到第二屏,也就 很容易看到「宣传文本」

这个新增字段对重运营的产品,可是个好消息。通常一个版本里运营会推好几拨活动,可惜描述不能随时更改,活动也无法同步到 App Store。「宣传文本」的存在,让 运营也能在 App Store 都做上文案推广啦

总结

秋季 iOS11 才会正式推出,到完成市场占有还有挺长一段时间,但 iTunes Connect 已经可以提交这些新字段的内容了,各位 ASOer 做好如何准备准备,相信能够轻松平稳过渡到后 ASO 时代:

  1. 提交新字段「subtitle」,同时兼顾好副标题的展现效果
  2. 可以提供适配三张应用截图/三个应用视频的设计方案
  3. 根据运营节奏更新「宣传文本」字段
  4. 来自榜单和类别的流量可能减少,要抓紧搜索入口,可以从技术手段上争取苹果的推荐位

笔者认为 App Store 的大改版至少看到了官方的两个态度:打击刷榜;强调营收。最终目的都是调整流量。

打击刷榜就好比游戏公司不许外挂了,人民币玩家会不爽,但对于从不用外挂的普通玩家而言,目前还算是好消息。

虽然独立的「游戏」,调整了入口的「类别」和「排行榜」多少都会影响到流量的导向,但新出的 subtitle、「宣传文本」和应用截图展现等等都扩大了运营空间。

 

参考资料

  1. WWDC2017:消失的榜单忧伤了苦逼的ASO
  2. 治大国如烹小鲜,苹果WWDC 2017之后App Store流量怎么玩?
  3. WWDC2017已结束,CP需要关注iTunes Connect开发者后台的重大调整!
  4. 刷榜公司哭了,App Store大改版,必将颠覆iOS的游戏玩法
  5. 【业界观点】苹果App Store大改版的三大疑问
  6. 如何上热搜?揭秘App Store热门搜索
  7. App Store排行榜从首页消失 刷榜还有用么
  8. 苹果App Store史上最大改版背后:刷榜生意难以为继!
  9. 如何评价 WWDC 2017 中发布的 App Store 的改版?
  10. App Store 2.0: New face of Apple App Store (WWDC 2017)

如何理解并正确使用 MySQL 索引

$
0
0

1、概述

索引是存储引擎用于快速查找记录的一种数据结构,通过合理的使用数据库索引可以大大提高系统的访问性能,接下来主要介绍在MySql数据库中索引类型,以及如何创建出更加合理且高效的索引技巧。

注:这里主要针对的是InnoDB存储引擎的B+Tree索引数据结构

2、索引的优点

1、大大减轻了服务器需要扫描的数据量,从而提高了数据的检索速度

2、帮助服务器避免排序和临时表

3、可以将随机I/O变为顺序I/O

3、索引的创建

3.1、主键索引

ALTER TABLE 'table_name' ADD PRIMARY KEY 'index_name' ('column');

3.2、唯一索引

ALTER TABLE 'table_name' ADD UNIQUE 'index_name' ('column');

3.3、普通索引

ALTER TABLE 'table_name' ADD INDEX 'index_name' ('column');

3.4、全文索引

ALTER TABLE 'table_name' ADD FULLTEXT 'index_name' ('column');

3.5、组合索引

ALTER TABLE 'table_name' ADD INDEX 'index_name' ('column1', 'column2', ...);

4、B+Tree的索引规则

创建一个测试的用户表

DROP TABLE IF EXISTS user_test;
CREATE TABLE user_test(
	id int AUTO_INCREMENT PRIMARY KEY,
	user_name varchar(30) NOT NULL,
	sex bit(1) NOT NULL DEFAULT b'1',
	city varchar(50) NOT NULL,
	age int NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

创建一个组合索引: ALTER TABLE user_test ADD INDEX idx_user(user_name , city , age);

4.1、索引有效的查询

4.1.1、全值匹配

全值匹配指的是和索引中的所有列进行匹配,如:以上面创建的索引为例,在where条件后可同时查询(user_name,city,age)为条件的数据。

注:与where后查询条件的顺序无关,这里是很多同学容易误解的一个地方

SELECT * FROM user_test WHERE user_name = 'feinik' AND age = 26 AND city = '广州';

4.1.2、匹配最左前缀

匹配最左前缀是指优先匹配最左索引列,如:上面创建的索引可用于查询条件为:(user_name )、(user_name, city)、(user_name , city , age)

注:满足最左前缀查询条件的顺序与索引列的顺序无关,如:(city, user_name)、(age, city, user_name)

4.1.3、匹配列前缀

指匹配列值的开头部分,如:查询用户名以feinik开头的所有用户

SELECT * FROM user_test WHERE user_name LIKE 'feinik%';

4.1.4、匹配范围值

如:查询用户名以feinik开头的所有用户,这里使用了索引的第一列

SELECT * FROM user_test WHERE user_name LIKE 'feinik%';

4.2、索引的限制

1、where查询条件中不包含索引列中的最左索引列,则无法使用到索引查询,如:

SELECT * FROM user_test WHERE city = '广州';

SELECT * FROM user_test WHERE age= 26;

SELECT * FROM user_test WHERE city = '广州' AND age = '26';

2、即使where的查询条件是最左索引列,也无法使用索引查询用户名以feinik结尾的用户

SELECT * FROM user_test WHERE user_name like '%feinik';

3、如果where查询条件中有某个列的范围查询,则其右边的所有列都无法使用索引优化查询,如:

SELECT * FROM user_test WHERE user_name = 'feinik' AND city LIKE '广州%' AND age = 26;

5、高效的索引策略

5.1、索引列不能是表达式的一部分,也不能作为函数的参数,否则无法使用索引查询。

SELECT * FROM user_test WHERE user_name = concat(user_name, ‘fei’);

5.2、前缀索引

有时候需要索引很长的字符列,这会增加索引的存储空间以及降低索引的效率,一种策略是可以使用哈希索引,还有一种就是可以使用前缀索引,前缀索引是选择字符列的前n个字符作为索引,这样可以大大节约索引空间,从而提高索引效率。

5.2.1、前缀索引的选择性

前缀索引要选择足够长的前缀以保证高的选择性,同时又不能太长,我们可以通过以下方式来计算出合适的前缀索引的选择长度值:

(1)

SELECT COUNT(DISTINCT index_column)/COUNT(*) FROM table_name; -- index_column代表要添加前缀索引的列

注:通过以上方式来计算出前缀索引的选择性比值,比值越高说明索引的效率也就越高效。

(2)

SELECT

COUNT(DISTINCT LEFT(index_column,1))/COUNT(*),

COUNT(DISTINCT LEFT(index_column,2))/COUNT(*),

COUNT(DISTINCT LEFT(index_column,3))/COUNT(*)

...

FROM table_name;

注:通过以上语句逐步找到最接近于(1)中的前缀索引的选择性比值,那么就可以使用对应的字符截取长度来做前缀索引了

5.2.2、前缀索引的创建

ALTER TABLE table_name ADD INDEX index_name (index_column(length));

5.2.3、使用前缀索引的注意点

前缀索引是一种能使索引更小,更快的有效办法,但是MySql无法使用前缀索引做ORDER BY 和 GROUP BY以及使用前缀索引做覆盖扫描。

5.3、选择合适的索引列顺序

在组合索引的创建中索引列的顺序非常重要,正确的索引顺序依赖于使用该索引的查询方式,对于组合索引的索引顺序可以通过经验法则来帮助我们完成:将选择性最高的列放到索引最前列,该法则与前缀索引的选择性方法一致,但并不是说所有的组合索引的顺序都使用该法则就能确定,还需要根据具体的查询场景来确定具体的索引顺序。

5.4 聚集索引与非聚集索引

1、聚集索引

聚集索引决定数据在物理磁盘上的物理排序,一个表只能有一个聚集索引,如果定义了主键,那么InnoDB会通过主键来聚集数据,如果没有定义主键,InnoDB会选择一个唯一的非空索引代替,如果没有唯一的非空索引,InnoDB会隐式定义一个主键来作为聚集索引。

聚集索引可以很大程度的提高访问速度,因为聚集索引将索引和行数据保存在了同一个B-Tree中,所以找到了索引也就相应的找到了对应的行数据,但在使用聚集索引的时候需注意避免随机的聚集索引(一般指主键值不连续,且分布范围不均匀),如使用UUID来作为聚集索引性能会很差,因为UUID值的不连续会导致增加很多的索引碎片和随机I/O,最终导致查询的性能急剧下降。

2、非聚集索引

与聚集索引不同的是非聚集索引并不决定数据在磁盘上的物理排序,且在B-Tree中包含索引但不包含行数据,行数据只是通过保存在B-Tree中的索引对应的指针来指向行数据,如:上面在(user_name,city, age)上建立的索引就是非聚集索引。

5.5、覆盖索引

如果一个索引(如:组合索引)中包含所有要查询的字段的值,那么就称之为覆盖索引,如:

SELECT user_name, city, age FROM user_test WHERE user_name = 'feinik' AND age > 25;

因为要查询的字段(user_name, city, age)都包含在组合索引的索引列中,所以就使用了覆盖索引查询,查看是否使用了覆盖索引可以通过执行计划中的Extra中的值为Using index则证明使用了覆盖索引,覆盖索引可以极大的提高访问性能。

5.6、如何使用索引来排序

在排序操作中如果能使用到索引来排序,那么可以极大的提高排序的速度,要使用索引来排序需要满足以下两点即可。

  • 1、ORDER BY子句后的列顺序要与组合索引的列顺序一致,且所有排序列的排序方向(正序/倒序)需一致
  • 2、所查询的字段值需要包含在索引列中,及满足覆盖索引

通过例子来具体分析

在user_test表上创建一个组合索引

ALTER TABLE user_test ADD INDEX index_user(user_name , city , age);

可以使用到索引排序的案例

1、SELECT user_name, city, age FROM user_test ORDER BY user_name;

2、SELECT user_name, city, age FROM user_test ORDER BY user_name, city;

3、SELECT user_name, city, age FROM user_test ORDER BY user_name DESC, city DESC;

4、SELECT user_name, city, age FROM user_test WHERE user_name = 'feinik' ORDER BY city;

注:第4点比较特殊一点,如果where查询条件为索引列的第一列,且为常量条件,那么也可以使用到索引

无法使用索引排序的案例

1、sex不在索引列中

SELECT user_name, city, age FROM user_test ORDER BY user_name, sex;

2、排序列的方向不一致

SELECT user_name, city, age FROM user_test ORDER BY user_name ASC, city DESC;

3、所要查询的字段列sex没有包含在索引列中

SELECT user_name, city, age, sex FROM user_test ORDER BY user_name;

4、where查询条件后的user_name为范围查询,所以无法使用到索引的其他列

SELECT user_name, city, age FROM user_test WHERE user_name LIKE 'feinik%' ORDER BY city;

5、多表连接查询时,只有当ORDER BY后的排序字段都是第一个表中的索引列(需要满足以上索引排序的两个规则)时,方可使用索引排序。如:再创建一个用户的扩展表user_test_ext,并建立uid的索引。

DROP TABLE IF EXISTS user_test_ext;

CREATE TABLE user_test_ext(

    id int AUTO_INCREMENT PRIMARY KEY,

    uid int NOT NULL,

    u_password VARCHAR(64) NOT NULL

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

ALTER TABLE user_test_ext ADD INDEX index_user_ext(uid);

走索引排序

SELECT user_name, city, age FROM user_test u LEFT JOIN user_test_ext ue ON u.id = ue.uid ORDER BY u.user_name;

不走索引排序

SELECT user_name, city, age FROM user_test u LEFT JOIN user_test_ext ue ON u.id = ue.uid ORDER BY ue.uid;

6、总结

本文主要讲了B+Tree树结构的索引规则,不同索引的创建,以及如何正确的创建出高效的索引技巧来尽可能的提高查询速度,当然了关于索引的使用技巧不单单只有这些,关于索引的更多技巧还需平时不断的积累相关经验。

如何理解并正确使用 MySQL 索引,首发于 文章 - 伯乐在线

记一次 MySQL 主从复制延迟的踩坑

$
0
0

最近开发中遇到的一个 MySQL 主从延迟的坑,记录并总结,避免再次犯同样的错误。

情景

一个活动信息需要审批,审批之后才能生效。因为之后活动要编辑,编辑后也可能触发审批,审批中展示的是编辑前的活动内容,考虑到字段比较多,也要保存审批活动的内容,因此设计采用了一张临时表,审批中的活动写进审批表(activity_tmp),审批通过之后才把真正的活动内容写进活动表(activity)。表的简要设计如下,这里将活动内容字段合并为content展示:

activity_tmp()
id
status // 审批状态    
content //  审批阶段提交的活动内容

activity
id
content // 审批通过后真正展示的活动内容

遇到的问题

当时是有编辑触发审批的情况,发现审批通过之后活动内容是空的,于是开始追查问题的原因。这里说一句,当程序出问题的时候,95%都是代码的问题,先不要去怀疑环境出问题。好好的查日志,然后看看你的代码吧。

追查问题回溯

1、查activity_tmp表,发现当时提交审批的活动内容是正常的,而且状态也更新为审批通过了,怀疑是写入activity表失败 2、查activity表,发现审批后的内容确实没有写入,怀疑是代码问题 3、查看代码,代码逻辑没看出问题,怀疑数据库操作失败,查看日志 4、日志显示,有一句insert语句的活动内容为空,活动内容来自上一个mysql执行的是select语句,把该select语句拿出来放到线上的备库查询,发现活动内容是存在的。运行时查询为空,执行完毕后查询时内容存在,初步怀疑是主从延迟问题。 5、报错只是部分失败,确定是主从延迟的问题。

当时的问题代码

$intStatus = $arrInput[‘status’];
$this->objActTmp->updateInfoByAId($intActId, $intStatus);
// 更新后,马上查
$arrActContent = $this->objActTmp->getActByStatus($intStatus);

这就是主从延迟出现的地方,update后,马上get,这是主从复制架构上开发的一个大忌。

解决方案

这类问题的解决方案有两种:

  • 修改代码逻辑
  • 修改系统架构

对于修改代码逻辑,鄙人有两点见解:

  • 如果第二步获取的数据不需要第一步更新的status字段,那就先读,然后再更新
  • 如果第二步获取的数据需要依赖第一步的status字段,那就在读出来的时候先判断是否为空,如果是空的,报错,下一次重试。

总结

其实之前也听到过这样的例子,但是由于没有亲身经历,所以只保留了一种理论上的记忆,实际上印象不深,经历了这么一次踩坑后,印象特别深刻,现在看到别人写这样的代码也能马上发现并指出。还是自己亲身去踩坑印象最深。

日志很重要,详细的日志更重要。日志要记录有用的信息,方便追查问题的时候去追溯问题的本质原因。我觉得日志就应该尽量做成飞机中的黑匣子,帮助我们保存“事故“发生时的所有相关信息。

记一次 MySQL 主从复制延迟的踩坑,首发于 文章 - 伯乐在线

数据库压缩技术探索

$
0
0
作者:雷鹏,Terark核心技术发明人。曾就职奇虎360,负责搜索引擎核心研发;曾就职Yahoo!北研所负责搜索广告、广告交易(AdExchange)等项目。在数据库、高性能计算、分布式、系统架构上都深有造诣。

作为数据库,在系统资源(CPU、内存、SSD、磁盘等)一定的前提下,我们希望:

  • 存储的数据更多:采用压缩,这个世界上有各种各样的压缩算法;
  • 访问的速度更快:更快的压缩(写)/解压(读)算法、更大的缓存。

几乎所有压缩算法都严重依赖上下文:

  • 位置相邻的数据,一般情况下相关性更高,内在冗余度更大;
  • 上下文越大,压缩率的上限越大(有极限值)。

块压缩

传统数据库中的块压缩技术

对于普通的以数据块/文件为单位的压缩,传统的(流式)数据压缩算法工作得不错,时间长了,大家也都习惯了这种数据压缩的模式。基于这种模式的数据压缩算法层出不穷,不断有新的算法实现。包括使用最广泛的gzip、bzip2、Google的Snappy、新秀Zstd等。

  • gzip几乎在在所有平台上都有支持,并且也已经成为一个行业标准,压缩率、压缩速度、解压速度都比较均衡;
  • bzip2是基于BWT变换的一种压缩,本质是上对输入分块,每个块单独压缩,优点是压缩率很高,但压缩和解压速度都比较慢;
  • Snappy是Google出品,优点是压缩和解压都很快,缺点是压缩率比较低,适用于对压缩率要求不高的实时压缩场景;
  • LZ4是Snappy一个强有力的竞争对手,速度比Snappy更快,特别是解压速度;
  • Zstd是一个压缩新秀,压缩率比LZ4和Snappy都高不少,压缩和解压速度略低;相比gzip,压缩率不相上下,但压缩/解压速度要高很多。

对于数据库,在计算机世界的太古代,为I/O优化的Btree一直是不可撼动的,为磁盘优化的Btree block/page size比较大,正好让传统数据压缩算法能得到较大的上下文,于是,基于block/page的压缩也就自然而然地应用到了各种数据库中。在这个蛮荒时代,内存的性能、容量与磁盘的性能、容量泾渭分明,各种应用对性能的需求也比较小,大家都相安无事。

现在,我们有了SSD、PCIe SSD、3D XPoint等,内存也越来越大,块压缩的缺点也日益突出:

  • 块选小了,压缩率不够;块选大了,性能没法忍;
  • 更致命的是,块压缩节省的只是更大更便宜的磁盘、SSD;
  • 更贵更小的内存不但没有节省,反而更浪费了(双缓存问题)。

于是,对于很多实时性要求较高的应用,只能关闭压缩。

块压缩的原理

使用通用压缩技术(Snappy、LZ4、zip、bzip2、Zstd等),按块/页(block/page)进行压缩(块尺寸通常是4KB~32KB,以压缩率著称的TokuDB块尺寸是2MB~4MB),这个块是逻辑块,而不是内存分页、块设备概念中的那种物理块。

启用压缩时,随之而来的是访问速度下降,这是因为:

  • 写入时,很多条记录被打包在一起压缩成一个个的块,增大块尺寸,压缩算法可以获得更大的上下文,从而提高压缩率;相反地,减小块尺寸,会降低压缩率。
  • 读取时,即便是读取很短的数据,也需要先把整个块解压,再去读取解压后的数据。这样,块尺寸越大,同一个块内包含的记录数目越多。为读取一条数据,所做的不必要解压就也就越多,性能也就越差。相反地,块尺寸越小,性能也就越好。

一旦启用压缩,为了缓解以上问题,传统数据库一般都需要比较大的专用缓存,用来缓存解压后的数据,这样可以大幅提高热数据的访问性能,但又引起了双缓存的空间占用问题:一是操作系统缓存中的压缩数据;二是专用缓存(例如RocksDB中的DBCache)中解压后的数据。还有一个同样很严重的问题:专用缓存终归是缓存,当缓存未命中时,仍需要解压整个块,这就是慢Query问题的一个主要来源(慢Query的另一个主要来源是在操作系统缓存未命中时)。

这些都导致现有传统数据库在访问速度和空间占用上是一个此消彼长、无法彻底解决的问题,只能采取一些折衷。

RocksDB 的块压缩

以RocksDB为例,RocksDB中的BlockBasedTable就是一个块压缩的SSTable,使用块压缩,索引只定位到块,块的尺寸在dboption里设定,一个块中包含多条(key,value)数据,例如M条,这样索引的尺寸就减小到了1/M:

  • M越大,索引的尺寸越小;
  • M越大,Block的尺寸越大,压缩算法(gzip、Snappy等)可以获得的上下文也越大,压缩率也就越高。

创建BlockBasedTable时,Key Value被逐条填入buffer,当buffer尺寸达到预定大小(块尺寸,当然,一般buffer尺寸不会精确地刚好等于预设的块尺寸),就将buffer压缩并写入BlockBasedTable文件,并记录文件偏移和buffer中的第一个Key(创建index要用),如果单条数据太大,比预设的块尺寸还大,这条数据就单独占一个块(单条数据不管多大也不会分割成多个块)。所有Key Value写完以后,根据之前记录的每个块的起始Key和文件偏移,创建一个索引。所以在BlockBasedTable文件中,数据在前,索引在后,文件末尾包含元信息(作用相当于常用的FileHeader,只是位置在文件末尾,所以叫footer)。

搜索时,先使用searchkey找到searchkey所在的block,然后到DB Cache中搜索这个块,找到后就进一步在块中搜索searchkey,如果找不到,就从磁盘/SSD读取这个块,解压后放入DB Cache。RocksDB中的DB Cache有多种实现,常用的包括LRU Cache,另外还有Clock Cache、Counting Cache(用来统计Cache命中率等),还有其他一些特殊的Cache。

一般情况下,操作系统会有文件缓存,所以同一份数据可能既在DB Cache中(解压后的数据),又在操作系统Cache中(压缩的数据)。这样会造成内存浪费,所以RocksDB提供了一个折衷:在dboption中设置DIRECT_IO选项,绕过操作系统Cache,这样就只有DB Cache,可以节省一部分内存,但在一定程度上会降低性能。

传统非主流压缩:FM-Index

FM-Index的全名是Full Text Matching Index,属于Succinct Data Structure家族,对数据有一定的压缩能力,并且可以直接在压缩的数据上执行搜索和访问。

FM-Index的功能非常丰富,历史也已经相当悠久,不算是一种新技术,在一些特殊场景下也已经得到了广泛应用,但是因为各种原因,一直不温不火。最近几年,FM-Index开始有些活跃,首先是GitHub上有个大牛实现了全套Succinct算法,其中包括FM-Index,其次Berkeley的Succinct项目也使用了FM-Index。

FM-Index属于Offline算法(一次性压缩所有数据,压缩好之后不可修改),一般基于BWT变换(BWT变换基于后缀数组),压缩好的FM-Index支持以下两个最主要的操作:

  • data = extract(offset, length)
  • {offset} = search(string) ,返回多个匹配string的位置/偏移(offset)

FM-Index还支持更多其他操作,感兴趣的朋友可以进一步调研。

但是,在笔者看来,FM-Index有几个致命的缺点:

  • 实现太复杂(这一点可以被少数大牛们克服,不提也罢);
  • 压缩率不高(比流式压缩例如gzip差太多);
  • 搜索(search)和访问(extract)速度都很慢(在2016年最快的CPU i7-6700K上,单线程吞吐率不超过7MB/sec);
  • 压缩过程又慢又耗内存(Berkeley的Succinct压缩过程内存消耗是源数据的50倍以上);
  • 数据模型是Flat Text,不是数据库的KeyValue模型。

可以用一种简单的方式把Flat Model转化成KeyValue Model:挑选一个在Key和Value中都不会出现的字符“#”(如果无法找出这样的字符,需要进行转义编码),每个Key前后都插入该字符,Key之后紧邻的就是Value。如此,search(#key#)返回了#key#出现的位置,我们就能很容易地拿到Value了。

Berkeley的Succinc项目在FM-Index的Flat Text模型上实现了更丰富的行列(Row-Column)模型,付出了巨大的努力,达到了一定的效果,但离实用还相差太远。

感兴趣的朋友可以仔细调研下FM-Index,以验证笔者的总结与判断。

Terark的可检索压缩(Searchable Compression)

Terark公司提出了“可检索压缩(Searchable Compression)”的概念,其核心也是直接在压缩的数据上执行搜索(search)和访问(extract),但数据模型本身就是KeyValue模型,根据其测试报告,速度要比FM-Index快得多(两个数量级),具体阐述:

  • 摒弃传统数据库的块压缩技术,采用全局压缩;
  • 对Key和Value使用不同的全局压缩技术;
  • 对Key使用有搜索功能的全局压缩技术COIndex(对应FM-Index的search);
  • 对Value使用可定点访问的全局压缩技术PA-Zip(对应FM-Index的extract)。

对Key的压缩:CO-Index

我们需要对Key进行索引,才能有效地进行搜索,并访问需要的数据。

普通的索引技术,索引的尺寸相对于索引中原始Key的尺寸要大很多,有些索引使用前缀压缩,能在一定程度上缓解索引的膨胀,但仍然无法解决索引占用内存过大的问题。

我们提出了CO-Index(Compressed Ordered Index)的概念,并且通过一种叫做Nested Succinct Trie的数据结构实践了这一概念。

较之传统实现索引的数据结构,Nested Succinct Trie的空间占用小十几倍甚至几十倍。而在保持该压缩率的同时,还支持丰富的搜索功能:

  • 精确搜索;
  • 范围搜索;
  • 顺序遍历;
  • 前缀搜索;
  • 正则表达式搜索(不是逐条遍历)。

与FM-Index相比,CO-Index也有其优势(假定FM-Index中所有的数据都是Key)。

表1 FM-Index对比CO-Index

CO-Index的原理

实际上我们实现了很多种CO-Index,其中Nested Succinct Trie是适用性最广的一种,在这里对其原理做一个简单介绍:

Succinct Data Structure介绍

Succinct Data Structure是一种能够在接近于信息论下限的空间内来表达对象的技术,通常使用位图来表示,用位图上的rank和select来定位。

虽然能够极大降低内存占用量,但实现起来较为复杂,并且性能低很多(时间复杂度的常数项很大)。目前开源的有SDSL-Lite,我们则使用自己实现的Rank-Select,性能也高于开源实现。

以二叉树为例

传统的表现形式是一个结点中包含两个指针:struct Node { Node *left, *right; };

每个结点占用 2ptr,如果我们对传统方法进行优化,结点指针用最小的bits数来表达,N个结点就需要2*[log2(N)]个bits。

  • 对比传统基本版和传统优化版,假设共有216个结点(包括null结点),传统优化版需要2 bytes,传统基本版需要4/8 bytes。
  • 对比传统优化版和Succinct,假设共有10亿(~230)个结点。
  • 传统优化版每个指针占用[log2(230)]=30bits,总内存占用:($frac{2*30}{8}$)*230≈ 7.5GB。
  • 使用Succinct,占用:($frac{2.5}{8}$)*230≈ 312.5MB(每个结点2.5 bits,其中0.5bits是 rank-select 索引占用的空间)。

Succinct Tree

Succinct Tree有很多种表达方式,这里列出常见的两种:

图1 Succinct Tree表达方式示例

Succinct Trie = Succinct Tree + Trie Label

Trie可以用来实现Index,图2这个Succinct Trie用的是LOUDS表达方式,其中保存了hat、is、it、a、四个Key。

Patricia Trie加嵌套

仅使用Succinct技术,压缩率远远不够,所以又应用了路径压缩和嵌套。这样一来,压缩率就上了一个新台阶。

把上面这些技术综合到一起,就是我们的Nest Succinct Trie。

对Value的压缩: PA-Zip

我们研发了一种叫做PA-Zip (Point Accessible Zip)的压缩技术:每条数据关联一个ID,数据压缩好之后,就可以用相应的ID访问那条数据。这里,ID就是那个Point,所以叫做Point Accessible Zip。

PA-Zip对整个数据库中的所有Value(KeyValue数据库中所有Value的集合)进行全局压缩,而不是按block/page进行压缩。这是针对数据库的需求(KeyValue 模型),专门设计的一个压缩算法,用来解决传统数据库压缩的问题:

  • 压缩率更高,没有双缓存的问题,只要把压缩后的数据装进内存,不需要专用缓存,可以按ID直接读取单条数据,如果把这种读取单条数据看作是一种解压,那么:
  • 按ID顺序解压时,解压速度(Throughput)一般在500MB每秒(单线程),最高达到约7GB/s,适合离线分析性需求,传统数据库压缩也能做到这一点;
  • 按ID随机解压时,解压速度一般在300MB每秒(单线程),最高达到约3GB/s,适合在线服务需求,这一点完胜传统数据库压缩:按随机解压300MB/s算,如果每条记录平均长度1K,相当于QPS = 30万;如果每条记录平均长度300个字节,相当于QPS = 100万;
  • 预热(warmup),在某些特殊场景下,数据库可能需要预热。因为去掉了专用缓存,TerarkDB的预热相对简单高效,只要把mmap的内存预热一下(避免Page Fault即可),数据库加载成功后就是预热好的,这个预热的Throughput就是SSD连续读的IO性能(较新的SSD读性能超过3GB/s)。

与FM-Index相比,PA-Zip解决的是FM-Index的extract操作,但性能和压缩率都要好得多:

表2 FM-Index对比PA-Zip

结合Key与Value

Key以全局压缩的形式保存在CO-Index中,Value以全局压缩的形式保存在 PA-Zip中。搜索一个Key,会得到一个内部ID,根据这个ID,去PA-Zip中定点访问该ID对应的Value,整个过程中只触碰需要的数据,不需要触碰其他数据。

如此无需专用缓存(例如RocksDB中的DBCache),仅使用mmap,完美配合文件系统缓存,整个DB只有mmap的文件系统缓存这一层缓存,再加上超高的压缩率,大幅降低了内存用量,并且极大简化了系统的复杂性,最终完成数据库性能的大幅提升,从而同时实现了超高的压缩率和超高的随机读性能。

从更高的哲学层面看,我们的存储引擎很像是用构造法推导出来的,因为CO-Index和PA-Zip紧密配合,完美匹配KeyValue模型,功能上“刚好够用”,性能上压榨硬件极限,压缩率逼近信息论的下限。相比其他方案:

    • 传统块压缩是从通用的流式压缩衍生而来,流式压缩的功能非常有限,只有压缩和解压两个操作,对太小的数据块没有压缩效果,也无法压缩数据块之间的冗余。把它用到数据库上,需要大量的工程努力,就像给汽车装上飞机机翼,然后要让它飞起来。
    • 相比FM-Index,情况则相反,FM-Index的功能非常丰富,它就必然要为此付出一些代价——压缩率和性能。而在KeyValue模型中,我们只需要它那些丰富功能的一个非常小的子集(还要经过适配和转化),其他更多的功能毫无用武之地,却仍然要付出那些代价,就像我们花了很高的代价造了一架飞机,却把它按在地上,只用轮子跑,当汽车用。
图2 用LOUDS方式表达的Succinct Tree

 

图3 路径压缩与嵌套

附录

压缩率&性能测试比较

数据集:Amazon movie data

Amazon movie data (~8 million reviews),数据集的总大小约为9GB, 记录数大约为800万条,平均每条数据长度大约1K。

Benchmark代码开源:参见 Github仓库
压缩率(见图4)

图4 压缩率对比

随机读(见图5)

图5 随机读性能对比

这是在内存足够的情况下,各个存储引擎的性能。
延迟曲线(见图6)

图6 延迟曲线对比

数据集:Wikipedia英文版

Wikipedia英文版的所有文本数据,109G,压缩到23G。

数据集:TPC-H

在TPC-H的lineitem数据上,使用TerarkDB和原版RocksDB(BlockBasedTable)进行对比测试:

表3 TerarkDB与原版RocksDB对比测试

API 接口

TerarkDB = Terark SSTable + RocksDB

RocksDB最初是Facebook对Google的LevelDB的一个fork,编程接口上兼容LevelDB,并增加了很多改进。

RocksDB对我们有用的地方在于其SSTable可以plugin,所以我们实现了一个RocksDB的SSTable,将我们的技术优势通过RocksDB发挥出来。

虽然RocksDB提供了一个相对完整的KeyValueDB框架,但要完全适配我们特有的技术,仍有一些欠缺,所以需要对RocksDB本身也做一些修改。将来可能有一天我们会将自己的修改提交到RocksDB官方版。

Github链接: TerarkDBhttps://github.com/Terark/terarkdb),TerarkDB包括两部分:

为了更好的兼容性,TerarkDB对RocksDB的API没有做任何修改,为了进一步方便用户使用TerarkDB,我们甚至提供了一种方式:程序无需重新编译,只需要替换 librocksdb.so并设置几个环境变量,就能体验TerarkDB。

如果用户需要更精细的控制,可以使用C++ API详细配置TerarkDB的各种选项。

目前大家可以免费试用,可以做性能评测,但是不能用于production,因为试用版会随机删掉0.1%的数据。

Terark命令行工具集

我们提供了一组命令行工具,这些工具可以将输入数据压缩成不同的形式,压缩后的文件可以使用Terark API或(该工具集中的)其他命令行工具解压或定点访问。

详情参见 Terark wiki中文版https://github.com/Terark/terark-wiki-zh_cn)。

数据库压缩技术探索,首发于 文章 - 伯乐在线

详解 equals() 方法和 hashCode() 方法

$
0
0

前言

Java的基类Object提供了一些方法,其中equals()方法用于判断两个对象是否相等,hashCode()方法用于计算对象的哈希码。equals()和hashCode()都不是final方法,都可以被重写(overwrite)。

本文介绍了2种方法在使用和重写时,一些需要注意的问题。

一、equal()方法

Object类中equals()方法实现如下:

public boolean equals(Object obj) {
    return (this == obj);
}

通过该实现可以看出,Object类的实现采用了区分度最高的算法,即只要两个对象不是同一个对象,那么equals()一定返回false。

虽然我们在定义类时,可以重写equals()方法,但是有一些注意事项;JDK中说明了实现equals()方法应该遵守的约定:

(1)自反性:x.equals(x)必须返回true。

(2)对称性:x.equals(y)与y.equals(x)的返回值必须相等。

(3)传递性:x.equals(y)为true,y.equals(z)也为true,那么x.equals(z)必须为true。

(4)一致性:如果对象x和y在equals()中使用的信息都没有改变,那么x.equals(y)值始终不变。

(5)非null:x不是null,y为null,则x.equals(y)必须为false。

二、hashCode()方法

1、Object的hashCode()

Object类中hashCode()方法的声明如下:

public native int hashCode();

可以看出,hashCode()是一个native方法,而且返回值类型是整形;实际上,该native方法将对象在内存中的地址作为哈希码返回,可以保证不同对象的返回值不同。

与equals()方法类似,hashCode()方法可以被重写。JDK中对hashCode()方法的作用,以及实现时的注意事项做了说明:

(1)hashCode()在哈希表中起作用,如java.util.HashMap。

(2)如果对象在equals()中使用的信息都没有改变,那么hashCode()值始终不变。

(3)如果两个对象使用equals()方法判断为相等,则hashCode()方法也应该相等。

(4)如果两个对象使用equals()方法判断为不相等,则不要求hashCode()也必须不相等;但是开发人员应该认识到,不相等的对象产生不相同的hashCode可以提高哈希表的性能。

2、hashCode()的作用

总的来说,hashCode()在哈希表中起作用,如HashSet、HashMap等。

当我们向哈希表(如HashSet、HashMap等)中添加对象object时,首先调用hashCode()方法计算object的哈希码,通过哈希码可以直接定位object在哈希表中的位置(一般是哈希码对哈希表大小取余)。如果该位置没有对象,可以直接将object插入该位置;如果该位置有对象(可能有多个,通过链表实现),则调用equals()方法比较这些对象与object是否相等,如果相等,则不需要保存object;如果不相等,则将该对象加入到链表中。

这也就解释了为什么equals()相等,则hashCode()必须相等。如果两个对象equals()相等,则它们在哈希表(如HashSet、HashMap等)中只应该出现一次;如果hashCode()不相等,那么它们会被散列到哈希表的不同位置,哈希表中出现了不止一次。

实际上,在JVM中,加载的对象在内存中包括三部分:对象头、实例数据、填充。其中,对象头包括指向对象所属类型的指针和MarkWord,而MarkWord中除了包含对象的GC分代年龄信息、加锁状态信息外,还包括了对象的hashcode;对象实例数据是对象真正存储的有效信息;填充部分仅起到占位符的作用, 原因是HotSpot要求对象起始地址必须是8字节的整数倍。

三、String中equals()和hashCode()的实现

String类中相关实现代码如下:

private final char value[];
private int hash; // Default to 0
public boolean equals(Object anObject) {
    if (this == anObject) {
        return true;
    }
    if (anObject instanceof String) {
        String anotherString = (String)anObject;
        int n = value.length;
        if (n == anotherString.value.length) {
            char v1[] = value;
            char v2[] = anotherString.value;
            int i = 0;
            while (n-- != 0) {
                if (v1[i] != v2[i])
                    return false;
                i++;
            }
            return true;
        }
    }
    return false;
}
public int hashCode() {
    int h = hash;
    if (h == 0 && value.length > 0) {
        char val[] = value;
        for (int i = 0; i < value.length; i++) {
            h = 31 * h + val[i];
        }
        hash = h;
    }
    return h;
}

通过代码可以看出以下几点:

1、String的数据是final的,即一个String对象一旦创建,便不能修改;形如String s = “hello”; s = “world”;的语句,当s = “world”执行时,并不是字符串对象的值变为了”world”,而是新建了一个String对象,s引用指向了新对象。

2、String类将hashCode()的结果缓存为hash值,提高性能。

3、String对象equals()相等的条件是二者同为String对象,长度相同,且字符串值完全相同;不要求二者是同一个对象。

4、String的hashCode()计算公式为:s[0]*31^(n-1) + s[1]*31^(n-2) + … + s[n-1]

关于hashCode()计算过程中,为什么使用了数字31,主要有以下原因:

1、使用质数计算哈希码,由于质数的特性,它与其他数字相乘之后,计算结果唯一的概率更大,哈希冲突的概率更小。

2、使用的质数越大,哈希冲突的概率越小,但是计算的速度也越慢;31是哈希冲突和性能的折中,实际上是实验观测的结果。

3、JVM会自动对31进行优化:31 * i == (i << 5) – i

四、如何重写hashCode()

本节先介绍重写hashCode()方法应该遵守的原则,再介绍通用的hashCode()重写方法。

1、重写hashcode()的原则

通过前面的描述我们知道,重写hashCode需要遵守以下原则:

(1)如果重写了equals()方法,检查条件“两个对象使用equals()方法判断为相等,则hashCode()方法也应该相等”是否成立,如果不成立,则重写hashCode ()方法。

(2)hashCode()方法不能太过简单,否则哈希冲突过多。

(3)hashCode()方法不能太过复杂,否则计算复杂度过高,影响性能。

2、hashCode()重写方法

Effective Java》中提出了一种简单通用的hashCode算法

A、初始化一个整形变量,为此变量赋予一个非零的常数值,比如int result = 17;
B、选取equals方法中用于比较的所有域(之所以只选择equals()中使用的域,是为了保证上述原则的第1条),然后针对每个域的属性进行计算:

(1) 如果是boolean值,则计算f ? 1:0
(2) 如果是byte\char\short\int,则计算(int)f
(3) 如果是long值,则计算(int)(f ^ (f >>> 32))
(4) 如果是float值,则计算Float.floatToIntBits(f)
(5) 如果是double值,则计算Double.doubleToLongBits(f),然后返回的结果是long,再用规则(3)去处理long,得到int
(6) 如果是对象应用,如果equals方法中采取递归调用的比较方式,那么hashCode中同样采取递归调用hashCode的方式。否则需要为这个域计算一个范式,比如当这个域的值为null的时候,那么hashCode 值为0
(7) 如果是数组,那么需要为每个元素当做单独的域来处理。java.util.Arrays.hashCode方法包含了8种基本类型数组和引用数组的hashCode计算,算法同上。

C、最后,把每个域的散列码合并到对象的哈希码中。 

下面通过一个例子进行说明。在该例中,Person类重写了equals()方法和hashCode()方法。因为equals()方法中只使用了name域和age域,所以hashCode()方法中,也只计算name域和age域。

对于String类型的name域,直接使用了String的hashCode()方法;对于int类型的age域,直接用其值作为该域的hash。

public class Person {
    private String name;
    private int age;
    private boolean gender;
    public Person() {
        super();
    }
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
    public int getAge() {
        return age;
    }
    public void setAge(int age) {
        this.age = age;
    }
    public boolean isGender() {
        return gender;
    }
    public void setGender(boolean gender) {
        this.gender = gender;
    }
    @Override
    public boolean equals(Object another) {
        if (this == another) {
            return true;
        }
        if (another instanceof Person) {
            Person anotherPerson = (Person) another;
            if (this.getName().equals(anotherPerson.getName()) && this.getAge() == anotherPerson.getAge()) {
                return true;
            } else {
                return false;
            }
        }
        return false;
    }
    @Override
    public int hashCode() {
        int hash = 17;
        hash = hash * 31 + getName().hashCode();
        hash = hash * 31 + getAge();
        return hash;
    }
}

相关文章

Viewing all 330 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>