Java并发也算告一段落了，也就是跟着大纲dei一下源码，加深下印象，真正能提高能力的还是的项目中用到，另外就是记录下最近遇到的几个问题。
1.Nacos的注册中心在AP模式下注册的是临时or持久实例？
2.范围查询用到索引了吗？
3.业务重要还是设计重要？
这几个问题都是近期遇到的问题，逐一想自我验证一下，还有我年初的计划是用心写30-35篇啊，这疫情原因，年初在家都写了将近20篇了，我还不高产吗？怎么还拖更掉粉了呢？
Nacos的注册中心在AP模式下注册的是临时or持久实例？
添加描述
问题提的挺好，自我理解的不够清晰，zk的AP模式是临时节点注册，那我理解的临时节点即挂掉就挂掉，不可恢复，至于影响其他节点是机制问题。
而Nacos是这样解释的：
临时和持久的区别主要是健康检查失败后的表现，持久化实例健康检查失败后会被标记不健康，而临时实例会被直接从列表中删除。
本来就此验证下是否真的如此，打开官网找到了Nacos的监控。
健康检查
以指定方式检查服务下挂载的实例 (Instance) 的健康度，从而确认该实例 (Instance) 是否能提供服务。根据检查结果，实例 (Instance) 会被判断为健康或不健康。对服务发起解析请求时，不健康的实例 (Instance) 不会返回给客户端
不知道我理解的对不对，我想的就是利用监控判断Nacos的健康状态
https://nacos.io/zh-cn/docs/monitor-guide.html根据Grafana的监控参数是可以明确的，但是需要集群部署，自己懒了点就没验证成功。
范围查询用到索引了吗?
讨论这个问题的时候我认为范围查询是不会用到索引的，以前被问过时间的字段范围查询可以用到索引吗？我说不可以，那么如何用到索引？看来是有方法可以用到的。
验证一下就好了
test表结构
创建索引
create index createTime ON dept(create_time)先验证下时间范围查询，id、create_time
in id,create_time
用到索引了吗？用到了，不管是范围还是in查询，都用到了...
但那就索引优化范围之后全失效是假的？
根据最佳左前缀法则，向右匹配遇到范围查询会停止匹配的，但其实mysql优化器查询时会尽量使用索引
查询条件并没用到最左侧的字段，优化器竟然用到了索引
业务重要还是设计重要？
关于这个问题就当下的业务展开进行了讨论，由于对业务的不不熟悉，在项目落参数时导致的参数不全，业务固然是代码书写的关键，何时落参，落哪些参数，在整个项目阶段，如果将业务捋清，流程理解，剩下的搬砖就是测试问题，所以每次项目开展都是设计先行，先输出接口，再细化过程。
而设计问题就会导致整个项目的扩展性，架构选择只是其中一方面，真正影响的还是业务设计，对后期的接入，扩展影响巨大，是否可抽离？是否可共用？是否强依赖？是否改动最小？最近感受比较深刻，当然这是历史设计遗留问题，时间久的项目考虑肯定没有那么细化，导致业务的模块与模块之间依赖太严重，不好抽离。
我明明很善良，
会给乞丐钱，
坐车会给老人让座，
无论做什么都会说声谢谢，
可世界万般苦，
却没有一件事情放过我。
