周记 6.19 - 6.25

时序数据库

时序数据库，简单的理解，就是按照时间来保存数据；例如，股票数据，温度....

时序数据特点: 大量写入，仅仅是插入，不会删除；少量读取；写多读少。

举个例子，假设我们需要保存温度时序记录，每0.5s设备采集一次记录，那么一天一台设备会添加172800条记录，如果需要保存全国各个县市(>3000)的记录，那么一天就会保存5亿条记录；同时我们还需要考虑每个城市不止会有一台温度采集设备，那么每天保存数据会是一个天文数字。

传统的MySql数据库能满足这个需求嘛，不能；MySql作为传统的OLAP数据库，不具备同时也不适用于时序型数据的保存；像MySql常用的B+ Tree索引存储结构，适用于读多写少的场景下。

为了解决B+ Tree的问题，业界提出了LSM结构，Log Structured Merge Trees，简单的理解，就是把数据像写入日志一般的写入存储空间；无论是磁盘还是SSD，有序写入相比无序写入速度快10倍以上，所以如果我们先把数据写入内存，然后等待数据积累到一定范围，一次性写入到磁盘，这样无疑会在速度上有很大的提升。

业界已经由很多现成的产品，例如阿里的 HiTSDB。

双端检锁

public class Test {

    public Helper getInstance() {
        return HelperSingleton.singleton;
    }

    private Helper instance;

    public Helper getInstanceLazy() {
        if (instance == null) {
            synchronized (this) {
                if (instance == null) {
                    instance = new Helper();
                }
            }
        }
        return instance;
    }
}
class HelperSingleton {
    static Helper singleton = new Helper();
}
class Helper {}

这样写是线程安全的嘛？会有什么问题嘛。

首先 instance = new Helper(); 是原子操作嘛，不是；执行new操作时，第一步，allocate分配存储空间；接着构造对象，执行构造方法；赋值对象地址给instance变量；注意，后两步顺序是不定的，因为java的重排序，两者情况都有可能。

想象一种情况。

线程A	线程B
第一次进入getInstanceLazy	-
分配存储空间	-
赋值给instance	-
-	进入getInstanceLazy
-	拿到instance对象地址
执行构造方法	-

如果按照这种顺序执行，线程B拿到了一个没有初始化对象，当使用这个对象时，就会导致出错。

那么如何规避这个问题呢，

    private volatile Helper instance;  // 变量加关键字修饰，这样就不会重排序

微服务

先分享一篇很棒的文章。

在传统的应用中，我们会把所有功能打成一个大的包，来进行上线发布；这样做的好处是线程都在一个大的进程中，代码之间相互调用简单；但问题是随着功能的增加，项目会越来越臃肿，而且随着开发人员的变多，代码管理复杂度也直线上升；在遇到这种情况下，大家首先想到的就是服务化，拆分应用。

但直接拆分业务真的好嘛，就我司隔壁部门服务化情况，效果并不理想；总结他们的失败教训，问题有:

1. 系统边界划分不明确，服务化本质其实是服务各司其职，系统边界一定要明确，不然在以后开发中就会越来越乱。
2. 分工问题，在服务化之后开发模式要及时转变，每个开发人员应该从功能开发转化为针对某个服务来进行开发；如果开发人员依然针对功能开发，从头写到未，那么服务化其实是没有意义的。
3. 日志跟踪，服务化后日志应该统一进行管理，不然在遇到问题查错时就非常费劲了。

SOA: Service-Oriented Atchitecture

在什么情况下不应该使用微服务呢?

1. 业务场景单一，逻辑简单，从长远上看不会有太大的改动。
2. 重要服务，比如交易系统；不能轻易重构。
3. 大家对微服务了解有限，采用微服务后开发、测试、部署都会有很大不同，在了解不够时不应该轻易采用微服务。

如果要引入微服务，Spring Cloud无疑会是首选，它具有分布式/版本控制、注册与发现、路由、服务调用、负载均衡、短路、分布式消息特点，引入它，可以快速构建一个稳定、可靠的服务。