不为无益之事，何遣有涯之生

近两年来，由于互联网规模再次扩大，原有的分布式技术（SOA、ESB等）都存在各种各样的缺陷，不能满足日益复杂的需求，所以各种新概念和框架应用而生，目前服务端最流行的是将复杂业务拆分微服务化，以减轻业务和代码的复杂度。在运维端，使用k8s和docker进行快速部署、扩容、监控、编排、回滚等常见运维操作，同时使用istio等Service mesh组件，达到分布式事务、track、router、限流、断路等常见服务需求。

参数

1. 快门：取值的倒数，数据越大快门速度越快。高速记录瞬间，低速记录过程；
2. 光圈：由于光圈值是以 2 的倍数变化的，直接用光圈数值表示镜头的通光量，光圈直径应呈 √2（约等于 1.4）系数关系递增。光圈值越大，通光量越小，景深越小；
3. 焦距：即镜片中心到 CMOS 底面的距离，焦距越长，景深越浅，且角度越小；短焦距的一般称作广角镜头，长焦距就称为长焦镜头。
4. 曝光补偿：用以修正曝光值；
5. 感光度（ISO）：感光度越大，需要的光线越少，但是图像的质量越低。在相同曝光值下，ISO 越低越好；
6. 长曝光：曝光时间超过 1s，一般用以夜拍，需要三脚架稳定，增大光圈获取更多光线；另外长曝光可以让运动物体呈现梦幻效果（车流、星轨、流水等）；

快门的参数

1. B 门（BuLb），也称为手控快门，是指按下快门时，快门打开，开始曝光，松开快门，快门关闭即停止曝光。也就是说，B 门是由快门按下时间的长短来决定每一次曝光时间的，无需设定曝光时间，可以自由控制。B 门的名称取自英语的“球”（bulb），它起源于旧时照相馆摄影师开启快门时所挤捏的橡皮球。这种橡皮球快门释放装置沿用至今，仍可以在很多现代照相馆的照相机上看到。
2. T 门，是指按下快门按钮快门打开，开始曝光，而且快门持续打开，直至再次按下按钮时快门关闭即停止曝光。T 门与 B 门在功能上比较接近，由于 T 门无需一直按住快门按钮，即可使快门持续打开，因此 T 门比 B 门使用方便一些。

长曝光

1. 白天的长时间曝光一般都可以直接使用相机的光圈优先模式，先选定光圈，然后由相机决定快门时间，30 秒内的曝光无需进入 M 档，如果相机出现 LO 字样，则需要切换到 M 档进行曝光；白天的长时间曝光，在相机能够自动识别场景，能进行自动对焦的时候，有主体的画面对着主体对焦，无明显主体的场景对着场景的前三分之一处对焦；有主体但是无法自动对焦时，用强光电筒照亮主体对焦处再按相机自动对焦按钮；对焦完成，切记要把对焦模式转为 MF 手动模式。
2. 夜间长时间曝光选用相机的 M 档（M 模式），先选定光圈，然后旋转相机的主拨轮调节快门时间，超过 30 秒后就出现 BULB，即相机的 B 门，用 B 门进行长时间曝光；用 B 门进行曝光的时候必须使用快门线；靠手按住相机的快门按钮进行长时间曝光是不现实的，晃动的几率太大，非常容易失败；

倒易率

倒易律指出底片的响应取决于总曝光量，即光线强度 × 时间。因此，在减少曝光时间但增加光线强度的情况下，底片的响应（比如显影后胶卷的光学密度）不变，反之亦然。 换句话说，一般对于某一给定的曝光结果，光圈与快门之间呈反比例关系，即若开大光圈则需要更快的快门以保持曝光不变。

本书原著为英文，即《Designing Data-Intensive Applications》，主要讲述数据库底层原理和设计思路，读来受益颇多。

基本原则

我们期望数据系统可靠、可扩展、可维护，但是由于 CAP 原理的限制，我们无法完全做到这些，因此在设计分布式数据库系统时，必然存在各种考量与限制。这里的数据库，指的不是狭义的关系型数据库，或者非关系型数据库。而是一种广泛的Data System，包括消息队列、RDBMS, NOSQL, 以及图数据库、列式数据库等等负责存储数据的组件。

redis是现在web开发中用的最广泛的组件之一了，用了很多年，是时候总结一下用法和经验了。

持久化

两个方案：DUMP和LOG。前者就是直接生成快照（SAVE），或者主进程fork一个进程（BGSAVE，内存使用要加倍）然后将内存里面的数据全部存入文件；后一个方案类似LSM-TREE的思路，将操作生成日志，并定期重写。

到 30 岁了，突然发现自己还是对编程理解的很浅，在此梳理一下技术栈，并准备新年的面试。

作为一个服务器开发工程师，涉及的技术相当之多，部分角度的深入理解需要花费大量时间，因此到最后一般是精通某个/几个方向，并对其他方向也有涉猎。

因为项目的需求更改，部分API与JSP之间的交互方式由直接渲染改成ajax，所以需要调研SpringMVC在Rest上最佳实践。下面是汇总的内容，参考了网上的一些文章。