zjy660358的专栏

OpenFeign 允许你自定义。

虽然合并单元格，但是读取还是有2行。如果是上面导出模板，那么导入的时候，2行在合并单元格列都能读取到数据。如果是新增的情况，那么只有在首行能读取到导入的合并单元格数据。介于一对一关系这边忽略。如果在导出的情况下修改，那么合并单元格也只能首行能读取到数据。

这条信息是来自 KingbaseES 数据库的一个 JDBC 客户端连接提示。KingbaseES 是一个企业级的关系型数据库管理系统，它兼容 PostgreSQL 的许多特性。如果上述步骤仍然无法解决问题，建议详细查看数据库和客户端的日志文件，以获取更具体的错误信息。此外，也可以考虑联系 KingbaseES 的技术支持获取帮助。项目融合kingbase数据库，输出日志乱码。结果：网上各种调整各种试。

SpringBoot整合SSE，实现后端主动推送DEMO前些日子写了整合SSE得demo。但是SSE对象是存储在ConcurrentHashMap中。在正式环境明显就不行了，服务重启一下的话都没有了。那么要持久化，第一选择放redisSseEmitterStoreController修改异步发送消息service跑起来之后，结果报错DefaultSerializer requires a Serializable payload but receiv

如果您是在企业级 Linux 发行版（如 RHEL/CentOS）上遇到此问题，您可能需要确保 SELinux 或其他安全策略不会阻止 IPv4 转发。您可以通过禁用 SELinux 或调整 SELinux 策略来解决此问题。这容器跑起来了，端口6379没用。搞的我一直怀疑哪里出错了，查看配置文件啊，命令啊。docker run 命令后，发现控制台有一个警告输出。： 您需要在内核中启用 IPv4 转发。改配置，并使其生效。

选择哪种方法取决于您的具体需求和资源。如果数据量非常大，建议先在一个较小的数据集上测试所选方法的性能，然后再应用到整个表。此外，在执行此类操作时，最好在业务低峰期进行，以减少对应用程序的影响。看来也没有更好的办法，还是这些老办法。

queryDatabaseForNewSecond==1 可以用来与库中对比，周期配置如有变更，那么需要更新。一开始打算在job中直接更新，更新也是需要停掉，再newScheduleBuilder、newTrigger，再启。毫无疑问，quartz更专业，功能更强大。支持事务，支持任务持久化。配置中，固定周期，单位秒。需要任务每间隔这个秒数 执行进行统计。用spring的schedule每一分钟同步一次。要实现这个需求，之前一直在用的多线程方案也行。本次就用quartz来实现动态任务。

业务逻辑中，当前时间于下次执行时间小于等于一分钟，创建任务。并且需要根据cron表达式知道上一次执行时间。二个时间是作为业务逻辑判断的条件。这边的now需要传入，因为需要忽略程序执行的毫秒级，所以需要每次对同一个时间进行操作。扩展循环次数来确保覆盖足够的周期。与前端协商，存储就用cron表达式。我给予修正了，符合自己的项目需求。，但是此文中提供的代码存在问题。2.3&2.4方法参考。月周日，都在符合预期。

三个对象，一个对象Point，一个对象CustomData。第三个对象IotDataCache用来屏蔽二者差异。问了AI 很多东西牛头不对马尾的，方法名对不上，参数有问题啊什么的。把Point的pointId 和 CustomData的id 都拷贝到IotDataCache中。有点基础的我相信都能看得懂。iotCode字段不变。

说起服务端主动推送，大家第一个想到的一定是WEBSOCKET。作为软件工程师，不能无脑使用一种技术，要结合实际情况，择优选取。SSE（Server-Sent Events）相比于WEBSOCKET1、轻量化、兼容性 基于传统的HTTP协议，所以浏览器兼容性比较好2、 只支持单向通讯。（服务器->客户端）

思路很清晰，原先用BcryptPasswordEncoder，那么继续用这个，只不过在这之前加上RSA解密。用了java.security自带的生成器。方法中，也有passwordEncoder。需要在解密进行异常捕获，密文不合规之类的。在 oauth认证服务器配置。附加解密后端util。

2、那么发送到同一个topic下，让各个业务系统来取，那么必定需要去过滤，不然拿到不属于本业务系统的点位信息了，仅仅靠tag明显是不够的，服务端过滤可以采用SQL92方式。点位编辑 需要新增勾选业务系统标识 tag - add ，移除勾选 tag - delete ，不变 tag - update。3、那么我随之就想到也可以在各个业务系统中过滤了，不是本业务系统的标识，直接返回。例：一个点位信息Bean，这个点位信息，设备、能源、安全都有用，那么点位信息表中有适用模块标识。模拟消费者一：业务系统标识为1。

虽说，synchronized 关键字万能的，在并发上去之后，这个插入就显得很慢了。仔细观察发现，其实锁的粒度还是再细点，可以根据AlarmRules对象的ID来锁。很明显synchronized(rules) 这个写法是有问题的。是基于对象的引用作为锁，只有在rules实例相同的情况下。我们实际情况实例不同，id相同的情况。ConcurrentHashMap（线程安全map） + ​ReentrantLock（可重入的锁）id不同的完美并发执行。

springboot启动警告。

RocketMQ版本4.9.4。

可以看到RemotingException、MQClientException、MQBrokerException时，Producer会自动重投消息，同步消息的重试选择其它Broker。实际情况可以根据业务需求改动，比如一定要发送成功的，后期每次重试休眠的时间随着重试次数增加。或者可以根据key 来记录，每个key 只能重试几次。重试是通过MQ内部去实现。如果超过了设定重试次数，就会抛出异常。通过设置可以设置同步消息重试次数。

其重试是通过MQClientAPIImpl的onExceptionImpl方法来实现，它会先判断重试次数，然后重新调用sendMessageAsync方法进行重试，调用过程中出现异常会根据异常类型再次执行onExceptionImpl方法。异步重试也是不会选择其他Broker的，该策略无法保证消息不丢失。异步又是效率优先，所以很多大拿都是。都知道通过设置，尝试是在MQClientAPIImpl 中完成。但是有些犟牛或者有些需求就要，再试试一定要成功，自定义。// 指定异步发送失败后不进行重试发送。

最后还是会保留topic下每个队列的最后一条。做了一些挣扎，无法取消队列最后一条。明明设置了CONSUME_FROM_LAST_OFFSET，还是会把历史消息查出来消费。最后把consumer_group8消费启用。消费者跑起来，组换成consumer_group8。console中手动新建消费组，把启用消费关掉。重置消费组offset。

最后一次失败直接进入死信队列、人工处理。发了100个对象消息。

id为1和9同queue，所以1报错，id9一定不会消费，那么返回SUSPEND_CURRENT_QUEUE_A_MOMENT 表示等一会，再继续处理这批消息。如果业务需求对于顺序消费 - 强要求，那么推荐在监听器中根据map中一定要根据重试次数采取一定措施，通知到人。如果顺序要求不高，或者不想这么麻烦，可以设置重试次数，使队列可以正常下去，做好记录及抛掉此消息后对后续消息影响的判断。根据试验，确实如此，重试默认时间间隔可以看出是1S。可以看到这条有问题的消息直接抛掉，消费ID9的了。