目录前言一、一次性全量二、定时任务增量三、强一致性问题四、canal框架4.1基本原理4.2安装使用（重点）版本说明4.3引入依赖（测试）4.4代码示例（测试）五、文章小结前言在日常项目开发中，可能会遇到使用ES做关键词搜索的场景，但是一般来说业务数据是不会直接通过CRUD写进ES的。因为这可能违背了ES是用来查询的初衷，数据持久化的事情可以交给数据库来做。那么，这里就有一个显而易见的问题：ES里的数据从哪里来？本文介绍的就是如何将MySQL的表数据迁移到ES的全过程。一、一次性全量该方案的思路很简单直接：将数据库中的表数据一次性查出，放入内存，在转换DB与ES的实体结构，遍历循环将DB的数据

目录引言目标驱动方法对比如何找到感兴趣的领域论文获取方法如何进入一个领域如何找到研究课题论文阅读方法后记引言   一提到学术论文，好像是研究生，博士才会涉及到的领域，对于本科生来说，看似有些困难，有些过于专业，好像有壁垒。其实本科生从十几年的“填鸭式”教育方法中一下走进了大学的“放养式”教育，很多同学会感到迷茫，没有目标去支撑自己，找不到方向。啃论文就提供这样一个方向，OpenHarmony啃论文俱乐部提供了一个很好的平台。我们如果在本科阶段深入一个领域去研究是一件很酷的事情，凭着自己的热爱早早背上行囊，储备知识，在自己最感兴趣的领域厚积薄发，听起来就已经热血沸腾了。  学术论文可以让我们更快

背景本篇文章会从系统架构设计的角度，分享在对业务安全风控相关基础安全产品进行系统设计时遇到的问题难点及其解决方案。内容包括三部分：（1）风控业务架构；（2）基础安全产品的职责；（3）基础安全产品相关系统架构的设计要点。文章会以总-分的形式进行阐述。懂的不多，做的太少。欢迎批评、指正。风控业务架构我把风控业务架构的分层分为6层，分别是组件层、业务层、决策层、能力层、计算层、可视层。以下基建为基础安全产品的简称。组件层组件层的职责是：数据收集与行为反制。从接口、设备、行为三个维度进行数据收集，接收决策层的指令进行行为反制。为了保证数据的收集数据的可靠性，就衍生出了壳、混淆、反调试等加固策略。更详细

题目：默认网络策略Context一个默认拒绝（default-deny）的NetworkPolicy可避免在未定义任何其他NetworkPolicy的namespace中意外公开Pod。Task为所有类型为 Ingress+Egress 的流量在namespace testing 中创建一个为 denypolicy 的新默认拒绝NetworkPolicy。此新的NetworkPolicy必须拒绝namespace testing 中的所有的 Ingress+Egress 流量。将新创建的默认拒绝NetworkPolicy应用在namespace testing 中运行的所有Pod。你可以在 /

技术不是万能的，但没有技术却可能是万万不能的，对于大模型可能也是如此。基于大模型的应用设计需要聚焦于所解决的问题，在自然语言处理领域，大模型本身在一定程度上只是将各种NLP任务统一成了sequence到 sequence 的模型。利用大模型，我们是在解决具体的生产和生活中的问题，产品和技术上的设计仍然不可或缺。那么，如果大模型正在重新构建软件工程的未来，我们是否应该遵循一些基本原则呢？1.模型优先，持续迭代如果模型能做到的是事情，就不要写代码；模型会变得更好，但代码不会。在当今的时代，模型的价值日益凸显。与传统的编程方法不同，现在的开发思路更倾向于“模型优先”。这意味着，当我们面临一个问题或任

1. 基本信息像火箭科学家一样思考：将不可能变为可能[美]奥赞·瓦罗尔（OzanVarol）著北京联合出版公司,2020年9月出版1.1. 读薄率书籍总字数250千字，笔记总字数37583字。读薄率37583÷250000≈15.03%1.2. 读厚方向起源：NASA天文学家的万物解答NASA系统工程手册（第2版）向NASA学工程师文化NASA的项目管理课：重塑影响项目成果的六大关键因素1.3. 笔记--章节对应关系笔记章节字数发布日期2023年读像火箭科学家一样思考笔记01_与不确定性共舞（上）第1章与不确定性共舞174511月18日读像火箭科学家一样思考笔记02_与不确定性共舞（下）第1章

1. 异常现象已成为常态1.1. 在NASA的文件中，反复出现的O形环问题被描述为“可接受的风险”，这是标准的做生意方式1.2. 冰水的温度与“挑战者”号发射时的环境温度类似，肉眼即可观测到，O形环失去了它的密封能力1.3. 尽管O形环损坏存在危险，但随着一次又一次飞行顺利完成，NASA开始对此习以为常，视野也变得越来越狭隘。1.4. 费曼将NASA的决策过程称为“俄罗斯轮盘赌”，由于那些存在O形环问题的航天飞机经过无数次飞行之后，并没有发生任何灾难性事件，所以NASA认为，“下一次飞行时，我们可以稍微降低一点标准，因为我们上次侥幸成功了”1.5. NASA内部人士所说的那样，随着时间的推移，

1. 开局与结局1.1. 我们学到了很多东西，知道以前很多做法是错误的，而学习有时会带来伤害。1.1.1. SpaceX高管汉斯·科尼格斯曼1.2. 单次失败和最终失败是有区别的1.2.1. 单次失败可以是开始而非结束1.2.2. 开局不一定要盛大，只要结局完美就行1.3. 时间改变了我们看待事件的方式，一些短期内看似失败的事物，在我们把目光放长远之后，就会发生逆转1.4. 突破性技术往往有一个进化的过程，它不是革命性的1.4.1. 只要研究任何一种科学发现，你就会注意到它不是凭空出现的，也不存在醍醐灌顶的时刻1.4.2. 科学由一个个失败积累而成，每个失败的版本都比以前的版本更好1.4.3.

一、问题windows平台进行gitadd时，控制台打印警告warning:intheworkingcopyof‘XXX.py’,LFwillbereplacedbyCRLFthenexttimeGittouchesit二、问题分析Dos/Windows平台默认换行符：回车（CR）+换行（LF），即’\r\n’Mac/Linux平台默认换行符：换行（LF），即’\n’企业服务器一般都是Linux系统进行管理，所以会有替换换行符的需求三、解决方法设置方法一：*适用于Windows系统，且一般为Windows默认设置，会在提交时对换行符进行CRLF-LF的转换，检出时又会进行LF-CRLF的转换。

自从事测试工作八年多以来，经历过三个部门多条业务线，也经历过测试转型再回到测试，在此过程中对测试工作和角色的认知也逐步有些思考，想把这些思考分享给大家，希望为业务测试同学提供一些有价值的思路。一、质量保障的本质是什么质量保障有很多工作，如发布前对业务需求的功能测试、性能测试、a/btest等，如发布后对线上的功能回归、冒烟巡检、异常监控等，我们做这些工作都围绕着“缺陷发现”，尽可能去发现系统潜在的bug，这似乎就是质量保障的所有内容和目的，但是可以跳出这些具体的工作内容，质量保障的本质到底是什么？我认为质量保障的本质：是一个尽力穷尽各种手段，不断去“证伪”的过程；是一个在有限条件和时间内，尽力