传统单体架构下，所有的功能模块都在一个应用下，所有的代码和业务逻辑都在同一个应用下实现，所以保证数据的一致性就很简单，保证相关操作都在同一个本地事务下就可以了。但是在微服务架构下，将一个应用拆分成了多个独立的服务，每个服务都能有自己的数据库，服务间通信都是通过远程调用实现，实现一个功能可能需要由几个不同的服务来共同实现。这就会带来一个问题，不同的服务之间无法做到使用同一个事务，这就无法保证数据的一致性了。

工作中时不时会被指派去排查线上问题，线上问题大致分成两种：一种是业务bug相关的，这种实际上没啥好讲的，无非就是程序运行结果不符合业务，一般都是看下相关日志，获取相关入参，在本地复现bug后修复即可。另一种则是排查程序是否能稳定运行，即在程序能完成预期的功能前提下，保证程序能够有较快的响应速度，不会出现明显的卡顿以及延迟。一般出现延迟或者卡顿的情况，服务器CPU使用率通常都会异常飙高。所以问题也就转换成了排查CPU为何飙高，以及应该如何解决。

多租户系统是一种将多个客户的数据和应用程序分开的系统，每个客户被视为一个独立的租户，互不干扰。实现多租户系统的关键之一是确保数据的隔离。之前公司的产品是一个多租户的SAAS平台，是一个面向企业办公的平台，每个企业其实就相当于一个租户。实际使用中采用可 数据行+数据表 混合的数据隔离方案，大多数业务场景中是数据行级别，即所有的数据都在同一张表下，用租户ID来区分。少部分业务场景则是数据表级别，每个租户都有自己的数据表，表名使用租户ID做后缀区分。

SQL 具有很高的灵活性，可以根据需求进行复杂的数据查询和分析，支持多表联合查询（join）、排序（order by）、分组（group by）、聚合（sum）等操作。虽然以上这些操作已经能解决绝大多的查询问题了，但是还是存在一些较为特殊的场景没法很好地处理。

在工作中，多多少少都会遇到一些数据展示的需求，开发一个接口，从数据库中查询数据返回页面展示。表结构是死的，但是查询需求却是非常灵活的。很多时候不是简单的直接从表中直接 select 获取数据就能够直接返回给页面，需要将一些判断，聚合逻辑交给 SQL 来做，才能够得到查询需求中的字段和数据。其中就可能会涉及到一些表行列的转换。以下用两个案例分别演示下行转列与列转行的业务场景，并给出通用的SQL写法。

如果单表的数据量过大，则会影响查询效率。想要解决这个问题，显然，直接拆分就完事了。一张表的数据量过多，那么进行分表，将数据分散到多张表中，每张表中的数据自然就不多了，问题就迎刃而解了。针对单表数据量大的情况，分库分表就是一个通用的解决方案。

在提升接口性能的方案中，毫无疑问，使用缓存是最有效果的，但同时也会带来新的问题。以上问题都是引入缓存需要考虑的，在设计时就需要做好相应的解决措施。

日常开发中设计接口，响应时间是衡量一个接口质量的重要指标。一般接口都是需要快速响应的，在不考虑任何优化策略的情况下，如果整个业务逻辑走下来，响应时间大于了2秒，那么就应该考虑对这个接口进行性能优化了，以免影响了用户的体验。

实际工作中大部分时间都是在写业务逻辑，一般都是三层架构，表示层（Controller）接收客户端请求，并对入参做检验，业务逻辑层（Service）负责处理业务逻辑，一般开发都是在这一层中写具体的业务逻辑。数据访问层（Dao）是直接和数据库交互的，用于查数据给业务逻辑层，或者是将业务逻辑层处理后的数据写入数据库。简单的增删改查接口不用多说，基本上写好一部分，剩下的都是复制粘贴然后稍微修改一下就行了，有些甚至可以用工具来直接生成。

Java 多线程开发中，一般需要用到线程池，线程池的大小应该如何设置？如果线程池太小，则无法压榨全部 cpu 性能，线程池太大的话，则过多的上下文切换，反而会起到反效果。