磁盘作为计算机的底层存储，重要性不言而喻，操作系统的启动程序就是存在在磁盘的开始位置上的。
磁盘是由多个盘片组成的，每个盘边两面都是可以存储数据。每个盘边对应一个读写磁头，所有读写磁头都是在同一个磁臂上，盘片则以每分钟3500转到10000转速率运转，即大约每6毫秒到17毫秒旋转一圈。该磁头由少量的空气垫层浮起，悬浮在盘面上方约几个微米的高度，磁头在盘面上的移动操作由一个伺服机构（ser-vomechanism）负责控制，注意不管是有多少个磁头，同一时间点只能有一个磁头处于活跃状态进行数据读写操作。
分区，又称为分片，是解决大数据存储的常见解决方案，大数据存储量超过了单节点的存储上限，因此需要进行分区操作将数据分散存储在不同节点上，通常每个单个分区可以理解成一个小型的数据库，尽管数据库能同时支持多个分区操作；分区引入多分区概念，可以同时对外服务提高性能。
关于数据序列化，首先要了解为什么需要序列化以及数据序列化的意义是什么，然后再了解下当前较为广泛的几种序列化方式。
为什么需要数据序列化呢？因为数据要“传输”，比如将数据网络通信传递给其他服务器，或者持久化到磁盘。那么传输为什么需要序列化呢？因此在内存中的数据，当前进程是知道数据格式和内容的，但是数据传输是二进制（或文本格式），所以需要有一个内存数据格式转换为二进制（或文本格式）的过程。数据序列化，可以进行数据压缩、数据格式多语言兼容等。下面就按照序列化的技术演变过程一起看下序列化的发展之路。
服务和数据的高可用性本质上是靠“复制”来解决的，比如服务通过集群部署多台机器来完成，数据通过冗余的多副本机制来完成。对于服务来说，只需要部署多个实例即可，特别是无状态服务，常见的微服务(dubbo/spring cloud)几乎都是通过集群部署对外提供服务能力，更进一步的还可使用k8s+docker技术自动管理服务的副本容量；对于数据来说，需要通过数据复制来保证数据节点的一致性，由于数据是有状态的，因此实现难度较服务复制成本要高。
通过sql分组查询数据时，一般通过group by来完成，group by默认取相同的分组列(一列或者多列)中第一个数据。
如果想获取sql分组中id最大的记录，我们可能想到的sql如下（name列作为分组）：
1 | select id,name from (select id,name from tt order by id desc) as t group by name |
TTL（transmittable-thread-local）是一个线程间传递ThreadLocal，异步执行时上下文传递的解决方案。整个库的核心是构建在TransmittableThreadLocal类（继承并加强InheritableThreadLocal类）之上，同时包含线程池修饰（ExecutorService/ForkJoinPool/TimerTask）以及Java Agent支持，代码小于1k行，短小精悍。
业务开发中，一般都会使用ThreadLocal保存一些上下文信息，但是在线程池中执行对应逻辑时，由于是不同线程所以无法获取之前线程的上下文信息。
线程池的线程上下文传递，实现方案就是在提交任务时记录当前线程上下文信息，在线程池中线程执行用户任务前将之前保存的上下文塞到当前线程的上下文中，在执行用户任务之后移除该上下文即可。简单来说就是，外部线程提交任务时要记录上下文信息，内部线程执行任务时获取之前记录的上下文信息设置到当前线程上下文中。
不知道小伙伴们有没有这样的困扰，平常开发中写单测，要mock一个复杂的对象，并且也知道了该对象的toString格式数据（比如从日志中获取），但是该怎么构建这个对象呢？
如果是json格式可以直接通过json反序列化得到对象，那么toString格式如何反序列得到对象呢？
Java并发工具类主要有CyclicBarrier、CountDownLatch、Semaphore和Exchanger，日常开发中经常使用的是CountDownLatch和Semaphore。下面就简单分析下这几个并发工具类：
CyclicBarrier底层借助于一个count计数器和Lock/Condition实现内存内存屏障功能，在对count–时必须先获取到lock，如果count不为0，则调用condition.wait进行阻塞操作；直到当count为0时，执行barrierCommand(如果配置的话，执行barrierCommand的线程是刚好将count减到0的那个线程)，然后调用condition.signalAll唤醒所有等待的线程。
3个线程依次打印1、2、3…这个问题，常常被作为面试题，题目如下：
三个线程，一个线程负责打印1，4，7，……；第二个负责打印2，5，8，……，第三个负责打印3，6，9，……，要求在控制台中按顺序输出1，2，3，4，5，6……。
Pod是kubernetes中最小的资源管理组件，Pod也是最小化运行容器化应用的资源对象。kubernetes中其他大多数组件都是围绕着Pod来进行支撑和扩展Pod功能的，例如，用于管理Pod运行的StatefulSet和Deployment等控制器对象，用于暴露Pod应用的Service和Ingress对象，为Pod提供存储的PersistentVolume存储资源对象等。
InfluxDB是一个开源的时序数据库，使用GO语言开发，特别适合用于处理和分析资源监控数据这种时序相关数据。而InfluxDB自带的各种特殊函数如求标准差，随机取样数据，统计数据变化比等，使数据统计和实时分析变得十分方便。
influxdb的单机版是开源的，而集群版是商业版，influxdb被设计运行在SSD上，如果使用机器或者网络磁盘作为存储介质，会导致性能下降至少一个数量级。influxdb支持restful api，同时也支持https，为了保证安全性，非局域网建议使用https与Influxdb进行通信。
InfluxDB是一个开源的时序数据库，使用GO语言开发，特别适合用于处理和分析资源监控数据这种时序相关数据。而InfluxDB自带的各种特殊函数如求标准差，随机取样数据，统计数据变化比等，使数据统计和实时分析变得十分方便。
influxdb的单机版是开源的，而集群版是商业版，influxdb被设计运行在SSD上，如果使用机器或者网络磁盘作为存储介质，会导致性能下降至少一个数量级。influxdb支持restful api，同时也支持https，为了保证安全性，非局域网建议使用https与Influxdb进行通信。
InfluxDB是一个开源的时序数据库，使用GO语言开发，特别适合用于处理和分析资源监控数据这种时序相关数据。而InfluxDB自带的各种特殊函数如求标准差，随机取样数据，统计数据变化比等，使数据统计和实时分析变得十分方便。
在目前的APM和后续的IoT场景中，InfluxDB会发挥越来越重要的作用，那么InfluxDB是如何保存数据并且高性能对外提供存取服务的呢？下面就一起来看下InfluxDB原理的那些事 ~
kubernetes（简称k8s）是一种用于在一组主机上运行和协同容器化应用程序的管理平台，皆在提供高可用、高扩展性和可预测性的方式来管理容器应用的生命周期。通过k8s，用户可以定义程序运行方式、部署升级策略、动态伸缩容，使得用户以一种更灵活可靠的方式来管理应用程序。
Docker是基于go语言开发，Linux下的底层技术主要基于cgroups、namespace以及联合文件技术实现的一种进程级别的轻量级虚拟化解决方案。由于Docker进程隔离独立于宿主机上其他进程，因此也称为容器，Docker在容器的基础上，进行了更进一步的封装，从文件系统、网络到进程隔离等，极大简化了容器的创建管理维护工作，降低了开发者使用门槛，因此才在近几年流行开来（毕竟Docker的底层技术在Docker出现之前就已经存在了）。
Namespace是将内核的全局资源做封装，使得每个Namespace都有一份独立的资源，因此不同的进程在各自的Namespace内对同一种资源的使用不会互相干扰。
目前Linux内核总共支持以下6种Namespace：
好的代码需不需要注释，这个问题其实不能直接说需要或者不需要，因为要视情况而定。如果一段代码功能较为简单且独立，同时代码风格较好，是不需要注释的，因为代码本身已经足够说明其用意了（代码即注释）；如果功能较复杂或者较为抽象，是需要合理注释的，方便他人阅读和快速理解代码逻辑。那么问题来了，什么是好的注释呢？就是简洁的表述自己当时的思考，即为什么，话句话说：应该表达“我的代码为什么要这么做？”，而不是表达“我的代码做了什么？”。必要的时候可以增加图形化说明，更加具体：
cgroup从2.6.4引入linux内核主线，目前默认已启用该特性。在cgroup出现之前，只能对一个进程做资源限制，比如通过sched_setaffinity设置进程cpu亲和性，使用ulimit限制进程打开文件上限、栈大小等。
cgroups是Linux下控制一个（或一组）进程的资源限制机制，全称是control groups，可以对cpu、内存等资源做精细化控制，比如目前很多的Docker在Linux下就是基于cgroups提供的资源限制机制来实现资源控制的；除此之外，开发者也可以指直接基于cgroups来进行进程资源控制，比如8核的机器上部署了一个web服务和一个计算服务，可以让web服务仅可使用其中6个核，把剩下的两个核留给计算服务。cgroups cpu限制除了可以限制使用多少/哪几个核心之外，还可以设置cpu占用比（注意占用比是各自都跑满情况下的使用比例，如果一个cgroup空闲而另一个繁忙，那么繁忙的cgroup是有可能占满整个cpu核心的）。