业务驱动下的单线程到多线程单应用到分布式（三）

理清材料工具准备就绪接下来要实现的是这样的系统：

在不影响其他端正常使用的情况下。数据拉取、处理、计算全部由CRM端自行解决，之后再对其他端公布可直接调用的接口数据

根据以上在十八般兵器中踩的坑再次罗列一下

1.与oracle 中count 的”千万”差距，实时查询绝对是个大屎坑，具体解决方案请参考章二中提到的

2.大小写敏感问题：具体查询 lower_case_table_names 关键字

真是个靠谱的家伙


REQUEST_TIMEOUT_MS_CONFIG	请求超时时间
ACKS_CONFIG	//## 0：不保证消息的到达确认，只管发送，低延迟但是会出现消息的丢失，在某个server失败的情况下，有点像TCP //## 1：发送消息，并会等待leader 收到确认后，一定的可靠性 //## -1：发送消息，等待leader收到确认，并进行复制操作后，才返回，最高的可靠性
MAX_POLL_RECORDS_CONFIG	限制消费方法每次最多取多少条数据，单条数据处理时间较长时应适当调整session 时间和单次获取条数
GROUP_ID_CONFIG	处于不同分组的多个消费者会重复消费数据
REQUEST_TIMEOUT_MS_CONFIG	不能小于 FETCH_MAX_WAIT_MS_CONFIG SESSION_TIMEOUT_MS_CONFIG 参数的值
offset 自动提交问题	业务偏重，处理尚需时间，自动提交出现错误不好处理Acknowledgment 中 acknowledge方法的使用

1. 了解 elastic 2 和 elastic 5 两个大版本的差距

2. 使用spring data elastic 理清楚 spring boot 和 spring data 框架的版本依赖

3. elastic用户验证 xpack的使用（这是个收费的大屎坑）具体破解方法请google ，我的5.5 反正是成功破解了。

4. elastic-header的使用

5.数据备份

1. logstash-log.conf 文件的格式和语法

kibana

        1.logtrail 插件的应用
          https://github.com/sivasamyk/logtrail
        2.结合生产环境做一定优化
spring boot

1.spring boot admin 是个让人眼馋的东西

发布了13 篇原创文章 · 获赞 0 · 访问量 7133

私信关注