周记 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; // 变量加关键字修饰，这样就不会重排序
微服务
先分享一篇很棒的文章。
在传统的应用中，我们会把所有功能打成一个大的包，来进行上线发布；这样做的好处是线程都在一个大的进程中，代码之间相互调用简单；但问题是随着功能的增加，项目会越来越臃肿，而且随着开发人员的变多，代码管理复杂度也直线上升；在遇到这种情况下，大家首先想到的就是服务化，拆分应用。
但直接拆分业务真的好嘛，就我司隔壁部门服务化情况，效果并不理想；总结他们的失败教训，问题有:
- 系统边界划分不明确，服务化本质其实是服务各司其职，系统边界一定要明确，不然在以后开发中就会越来越乱。
- 分工问题，在服务化之后开发模式要及时转变，每个开发人员应该从功能开发转化为针对某个服务来进行开发；如果开发人员依然针对功能开发，从头写到未，那么服务化其实是没有意义的。
- 日志跟踪，服务化后日志应该统一进行管理，不然在遇到问题查错时就非常费劲了。
SOA: Service-Oriented Atchitecture
在什么情况下不应该使用微服务呢?
- 业务场景单一，逻辑简单，从长远上看不会有太大的改动。
- 重要服务，比如交易系统；不能轻易重构。
- 大家对微服务了解有限，采用微服务后开发、测试、部署都会有很大不同，在了解不够时不应该轻易采用微服务。
如果要引入微服务，Spring Cloud无疑会是首选，它具有分布式/版本控制、注册与发现、路由、服务调用、负载均衡、短路、分布式消息特点，引入它，可以快速构建一个稳定、可靠的服务。
