解决方案:写文案不难，你可以用AI人工智能仿写在线生成啊
优采云 发布时间: 2022-11-19 16:14解决方案:写文案不难，你可以用AI人工智能仿写在线生成啊
什么是AI人工智能模仿在线工具？想写文章的朋友都需要，我为什么这么说呢？经常听人说写文案难，文案不知从何下手，文案写了又删，删了又写，写一篇要几个小时等等。不喜欢的人写作，真的很难写一个。但是，由于工作的原因，有时不得不写而不能写，这让很多人很伤心。那么，面对文案，做起来难吗？别担心，这里有一个方法告诉你，我们只需要使用这个免费的一键式伪原创工具，就可以轻松写出好文案。
这里使用的AI人工智能模仿在线工具是智能媒体ai的伪原创。我将详细解释如何操作。
写文案难，AI人工智能模仿在线工具给你
想用AI人工智能模仿在线工具请看图片和文字，网上找
" />
在使用免费的一键伪原创工具之前，我们先了解一下这个工具主要是AI自动处理文案的工具。它的功能非常强大，包括文案伪原创处理、关键词自动生成文案、原创文案检测、文案智能灵感创作等功能。智媒AI伪原创工具采用自然语言处理技术，可以深度理解和分析文案内容，在不改变文案语义的情况下，自动生成新的文案内容。
如何使用免费的一键伪原创工具（AI人工智能仿在线）写文案？
写文案难，AI人工智能模仿在线工具给你
每个人都想免费使用它：
1、到AI模仿在线工具官网登录，获取免费积分免费使用
" />
2、进入AI人工智能模仿在线工具官网新闻栏目页面，对以上文章进行评论。您还可以获得相应的免费积分并免费使用。
有两种方法：
1、找到相关文案的素材，使用智能AI模仿在线工具对原件进行处理，生成全新的文案。
2、制作AI模仿在线工具客户端版，找到上面的“创作模式”，只需要输入文案的关键词即可。AI人工智能模仿在线工具，可自动生成高质量文案。
这两种写文案的方式就是帮助大家快速的创作出一份好的文案，彻底解放头脑和双手。因此，您再也不用担心不会写文案了。
好了，看了上面的介绍，大家觉得文案写起来有难度。只要使用AI人工智能文案在线工具（看图看文字，找找），就可以轻松解决文案难的问题。
分享:如何设计日志采集系统？不妨看看这篇文章
概述
日志从最初面向人类到面向机器的演变发生了巨大变化。最初，日志的主要消费者是读取日志以解决问题的软件工程师，如今，大量机器日夜处理日志数据以生成可读的报告，以帮助人类做出决策。在这个转换过程中，日志采集
代理在其中扮演着重要的角色。
作为日志
采集代理只是一个将数据从源头传递到目的地的程序，通常目的地是具有数据订阅功能的集中存储，这样做的目的其实是将日志分析和日志存储解耦，同一个日志可能会有不同的消费者感兴趣，获取日志后的处理方式会有所不同， 通过数据存储和数据分析解耦，不同的消费者可以订阅自己感兴趣的日志，选择相应的分析工具进行分析。业内最流行的具有数据订阅功能的集中存储是Kafka，它对应于阿里巴巴内部的DataHub和阿里云的LogHub。数据源大致可以分为三类，一类是普通文本文件，另一类是通过网络接收的日志数据，最后一类是通过共享内存，本文只讲第一类。日志采集
代理的核心功能大致是这样的。在此基础上，可以引入日志过滤、日志格式化、路由等功能，看起来像一个生产车间。从日志下发的角度来看，日志采集可分为推送模式和拉取模式，本文主要分析推送模式下的日志采集。
推送模式是指日志采集代理主动从源端获取数据
并将其发送到目的端，而拉取模式意味着目标主动从源端从日志采集
代理获取数据。
行业现状
目前业界比较流行的日志采集主要包括Fluentd、Logstash、Flume、scribe等，阿里巴巴就是LogAgent，阿里云就是LogTail，这些产品Fluent占据了绝对优势，成功进入了CNCF阵营，它提出的统一日志层大大降低了整个日志采集和分析的复杂性。Fluentd认为，现有的大多数日志格式结构很差，这要归功于人类对日志数据的出色解析能力，而人类是他们日志数据的主要消费者。为此，Fluentd 希望通过统一的日志存储格式来降低整个日志采集访问的复杂度，假设输入的日志数据有 M 种格式，日志采集代理后端访问 N 种存储，那么每个存储系统都需要实现 M 种日志格式解析功能，总复杂度为 M*N， 如果日志采集
代理统一了日志格式，则总复杂度变为 M + N。这是Fluentd的核心思想，它的插件机制也是一个值得称道的点。Logstash 和 Fluentd 类似于 ELK 技术堆栈，在业界应用广泛，有关两者的比较，请参阅本文 Fluentd vs. Logstash：日志采集
器的比较：
从头开始编写日志采集
代理
作为日志采集代理在大多数人眼中可能是数据“搬运工”，但也经常抱怨这个“搬运工”占用了太多的机器资源，简单来说就是一个尾部-f命令，这是最贴切的，对应的Fluentd就是in_tail插件。作为亲身实践过日志采集
代理的开发者，希望通过本文普及到日志采集
代理开发过程中的一些技术挑战。为了使文章的整个上下文具有连续性，笔者试图通过“从头开始编写日志采集
代理”的主题来描述整个开发过程中遇到的问题。
如何找到文件？
当我们开始编写日志采集
代理时，遇到的第一个问题是如何找到文件，最简单的方法是用户直接列出要采集
的文件和
" />
把它们放在配置文件中，然后日志采集
代理会读取配置文件，找到要采集
的文件列表，最后打开这些文件进行采集
，这可能是最简单的。但是，大多数情况下，日志是动态生成的，并且在日志采集
过程中会动态创建，提前在配置文件中列出它们太麻烦了。一般情况下，用户只需要配置一个日志采集目录和文件名匹配规则，比如 Nginx 的日志放在 /var/www/log 目录下，日志文件的名称是 access.log、access.log-2018-01-10.....与此形式类似，为了描述此类文件，此类文件可以用通配符或常规表示形式匹配，例如：access.log（-[0-9） {4}-[0-9]{2}-[0-9]{2}）？使用此类描述规则，日志采集
代理可以知道需要采集
哪些文件，哪些文件不需要采集
。接下来你会遇到的另一个问题是如何找到新创建的日志文件？，这可能是定期轮询目录的好方法，但是轮询周期太长会导致实时性不足，太短并且会消耗CPU，并且您不希望您的采集
代理被抱怨占用过多CPU。
Linux 内核为我们提供了一种高效的 Inotify 机制，其中内核监控对目录中文件的更改，然后通过事件通知用户。但是不要高兴太早，Inotify 并没有我们想象的那么好，它有一些问题，首先并不是所有的文件系统都支持 Inotify，另外，它不支持递归目录监控，比如我们监控 A 目录，但是如果在 A 目录下创建了 B 目录，然后立即创建 C 文件， 那么我们只能得到 B 目录创建的事件，C 文件创建的事件就会丢失，最终会导致这个文件没有被发现和采集
。对于现有文件，Inotify 无法执行任何操作，Inotify 只能实时发现新创建的文件。Inotify 手册页详细介绍了使用 Inotify 时的一些限制和错误。如果您想确保没有遗漏的地雷，那么最好的解决方案是结合 Inotify+ 轮询。通过较大的轮询周期来检测丢失的文件和历史文件，Inotify 确保在大多数情况下可以实时找到新创建的文件，即使在不支持 Inotify 的场景中，仅轮询也能正常工作。此时，我们的日志采集
代理可以找到该文件，因此我们需要打开此文件并采集
它。但是有不可预见的风暴，机器在我们采集
的过程中崩溃了，我们如何确保已经采集
的数据不再被采集
，并且可以继续上次没有采集
的地方？
基于轮询的方法的优点是保证不会遗漏任何文件，除非文件系统中出现bug，并且可以通过增加轮询周期来避免CPU，但实时性能还不够。尽管Inotify非常高效和实时，但它不能保证100%无事件。因此，通过结合轮询和 Inotify，您可以相互补充。
点文件高度可用
点文件？对是通过点文件记录文件名和对应的采集位置。那么如何保证这个点文件能够可靠地写入呢？因为机器可能会在写入文件的那一刻崩溃，导致点数据丢失或数据无序。要解决此问题，您需要确保文件写入成功或失败，并且绝不能出现写入完成一半的情况。Linux 内核为我们提供了原子重命名。一个文件可以原子重命名为另一个文件，此功能可以保证点文件的高可用性。假设我们已经有一个名为 offset 的点文件，每秒更新这个点文件，采集到的位置实时记录，整个更新过程如下：
将点数据写入磁盘的偏移.bak文件
fdatasync 确保数据写入磁盘
通过调用重命名系统将偏移.bak重命名为偏移通过这种方式，保证点文件在
任何时候都是正常的，因为每次写入都会首先保证写入临时文件成功，然后原子替换它。这保证了偏移文件始终可用。在极端情况下，1秒内的点不会及时更新，日志采集
代理在启动后会在1秒内再次采集
数据，基本符合要求。
然而，
文件名和对应的采集位置都记录在点文件中，会带来另一个问题，如果在崩溃过程中文件被重命名怎么办？然后开始后，找不到相应的采集
位置。在这种日志的场景中，文件名其实很不靠谱，文件的重命名、删除、软链等会导致同一个文件名在不同时间实际指向不同的文件，将整个文件路径保存在内存中其实是非常占用内存的。Linux内核提供inode可以作为文件的标识信息，保证inode不会同时重复，这样就可以解决上述问题，并且可以在点文件中记录文件的inode和集合的位置。日志采集代理启动后，通过文件发现找到要采集的文件，获取 Inode，从点文件中查找对应的采集位置，然后继续采集。那么即使文件被重命名，它的 Inode 也不会改变，所以从点文件中找到对应的采集位置还是可以的。但是Inode有什么限制吗？当然，世界上没有免费的午餐，不同的文件系统 Inode 会被复制，一台机器可以挂载多个文件系统，所以我们还需要通过 dev（设备号）进一步区分，所以点文件中需要记录的是 dev、inode、offset 三元组。此时，我们的采集
代理可以正常采集
日志，即使再次启动崩溃，它仍然可以继续采集
。但是突然有一天我们发现有两个文件其实是同一个 Inode，Linux 内核不保证同一个时间不会重复吗？注意我用的是“同时”，内核只能保证不会同时重复，这是什么意思？这是日志采集
代理遇到的一个比较大的技术挑战，如何准确识别一个文件。
如何识别文件？
如何识别文件是一个
在日志采集
代理中更具挑战性的技术问题，我们先通过文件名进行识别，然后发现文件名不可靠且消耗资源，然后我们改为dev+Inode，却发现Inode只能保证同一时间Inode不重复，那么这句话是什么意思呢？想象一下，在 T1 时刻有一个文件 Inode 是 1 我们找到它并开始采集
，删除一段时间后，Linux 内核会释放 Inode，创建新文件后，Linux 内核会将新发布的 Inode 分配给新文件。然后在发现新文件后，它将查询上次采集
的位置来自点文件，结果将找到上一个文件中记录的点，从而导致从错误的位置采集
新文件。如果能在每个文件上放一个唯一标识符可以解决这个问题，好在 Linux 内核为文件系统提供了扩展属性 xattr，我们可以为每个文件生成一个唯一标识符记录在点文件中，如果文件被删除，然后创建一个新文件即使 Inode 相同， 但文件 ID 不同，日志采集
代理可以识别这是两个文件。但问题是，并非所有文件系统都支持 xattr 扩展属性。因此，扩展属性只能解决部分问题。也许我们可以通过文件的内容来解决这个问题，我们可以读取文件的前 N 个字节作为文件 ID。这也是一个解决方案，但这个 N 有多大？相似度越大，相同的概率越小，无法识别的概率越小。一个真正 100% 可识别的通用解决方案仍有待研究，假设 80% 的问题在这里得到解决。然后就可以放心地进行日志采集了，日志采集其实就是读取文件，读文件的过程中需要注意的是尽可能多的读取顺序，充分利用Linux系统缓存，必要时可以使用posix_fadvise在采集日志文件后清除页面缓存，主动释放系统资源。那么什么时候该采集
文件呢？当 EOF 在集合结束时返回时，集合已完成。但是过了一段时间，日志文件中会生成新的内容，你怎么知道有新的数据，然后继续采集
？
" />
如何知道文件内容是否已更新？
Inotify 可以解决这个问题，并通过 Inotify 监控一个文件，所以只要文件有新的数据，就会触发一个事件，获取事件后可以继续采集
。但是这种方案有一个问题，就是在大量文件写入的场景下会导致事件队列溢出，比如用户连续写入日志N次就会生成N个事件，其实对于日志采集
代理来说，只要知道要更新的内容， 至于更新多少次这个并不重要，因为每次采集其实都是连续读取文件，直到EOF，只要用户在不断写入日志，那么它就会继续采集。此外，Intopy可以监视的文件数量也有限制。因此，这里最简单也是最常见的解决方案是轮询查询要采集的文件的统计信息，如果文件内容更新了就采集
，采集
完成后再触发下一次轮询，简单多样。通过这些方式，日志采集
代理终于可以不间断地继续采集
日志了，既然日志总是会被删除，那么如果我们在采集
的过程中删除了日志会怎样？你可以放心，Linux 中的文件是有引用计数的，即使删除了已经打开的文件，也只是引用计数减去 1，只要有进程引用，就可以继续读取内容，所以日志采集
代理可以安心继续读取日志， 然后释放文件的FD，这样系统就可以真正删除文件了。但是你怎么知道它已经完成了呢？废话，上面并没有说采集
到文件末尾就是集合完成了，但是如果此时有另一个进程也打开了这个文件，在你采集
完所有内容并附加一段内容之后，你此时已经释放了fd， 在文件系统上这个文件已经不存在了，没有办法通过文件发现找到这个文件，打开并读取数据，我该怎么办？
如何安全地释放文件句柄？
Fluentd 处理这部分的方式是将这部分责任推给用户，让用户配置一个时间，如果文件删除后指定时间范围内没有添加数据，则释放 fd，这实际上是一种间接转储行为。这个时间配置太小会增加丢失数据的概率，这个时间配置太大会导致FD和磁盘空间一直被占用，造成短时间内免费浪费的错觉。这个问题的本质是，我们不知道还有谁在引用这个文件，如果还有人引用这个文件可能会写入数据，这个时候即使你释放的fd资源还是被占用了，最好不要释放，如果没有人在引用这个文件，那么其实， 您可以立即释放FD。你怎么知道谁在引用这个文件？你必须已经使用 lsof -f 列出系统中进程打开的文件，此工具扫描每个进程的 /proc/PID/fd/ 目录下的所有文件描述符，您可以通过 readlink 查看该描述符对应的文件路径，如以下示例：
tianqian-zyf@ubuntu:~$ sudo ls -al /proc/22686/fd<br />total 0<br />dr-x------ 2 tianqian-zyf tianqian-zyf 0 May 27 12:25 .<br />dr-xr-xr-x 9 tianqian-zyf tianqian-zyf 0 May 27 12:25 ..<br />lrwx------ 1 tianqian-zyf tianqian-zyf 64 May 27 12:25 0 -> /dev/pts/19<br />lrwx------ 1 tianqian-zyf tianqian-zyf 64 May 27 12:25 1 -> /dev/pts/19<br />lrwx------ 1 tianqian-zyf tianqian-zyf 64 May 27 12:25 2 -> /dev/pts/19<br />lrwx------ 1 tianqian-zyf tianqian-zyf 64 May 27 12:25 4 -> /home/tianqian-zyf/.post.lua.swp<br />
22686 此过程打开一个文件，fd 为 4，对应的文件路径为 /home/tianqian-zyf/.post.lua.swp。通过这种方法可以查询到文件的引用计数，如果引用计数为1，即只有当前进程的引用，那么基本上可以安全地释放fd，不会造成数据丢失，但问题是开销有点大，需要遍历所有进程查看自己打开的文件表逐一对比， 复杂度是O（n），如果你能做O（1）这个问题就完美解决了。搜索相关信息后，我发现在用户模式下几乎不可能做到这一点，并且 Linux 内核不会公开相关 API。这只能通过内核来解决，比如添加一个 API 通过 fd 获取文件的引用计数。这在内核里还是比较容易做到的，每个进程保存打开的文件，在内核里是结构文件结构，通过这个结构可以找到这个文件对应的结构 inode 对象，这个对象维护引用计数值。让我们希望 Linux 内核能够提供相关的 API 来完美地解决这个问题。
总结到目前为止，已经
介绍了基于文件采集
的Agen所涉及的核心技术点，其中涉及大量的文件系统和Linux相关知识，只有掌握了这些知识，才能更好地控制日志采集。编写可靠的日志采集
代理以确保数据不会丢失的复杂性和挑战不容忽视。希望这篇文章能让读者对日志采集有更全面的了解！
结束
<p data-darkmode-bgcolor="rgb(36, 36, 36)" data-darkmode-original-bgcolor="rgb(255, 255, 255)" data-darkmode-color="rgb(230, 230, 230)" data-darkmode-original-color="rgb(0, 0, 0)" data-darkmode-bgcolor-15923650965579="rgb(36, 36, 36)" data-darkmode-original-bgcolor-15923650965579="rgb(255, 255, 255)" data-darkmode-color-15923650965579="rgb(230, 230, 230)" data-darkmode-original-color-15923650965579="rgb(0, 0, 0)" style="margin-right: 0em;margin-left: 0em;text-align: center;"><strong data-darkmode-bgcolor="rgb(36, 36, 36)" data-darkmode-original-bgcolor="rgb(255, 255, 255)" data-darkmode-color="rgb(21, 189, 255)" data-darkmode-original-color="rgb(0, 122, 170)" data-darkmode-bgcolor-15923650965579="rgb(36, 36, 36)" data-darkmode-original-bgcolor-15923650965579="rgb(255, 255, 255)" data-darkmode-color-15923650965579="rgb(21, 189, 255)" data-darkmode-original-color-15923650965579="rgb(0, 122, 170)" style="font-size: 16px;letter-spacing: 0.544px;">有热门推荐</strong>
2. IntelliJ IDEA 超全优化设置，效率杠杠的！
4. RabbitMQ 线上事故！慌的一批，脑袋一片空白。。。
最近面试BAT，整理一份面试资料《Java面试BATJ通关手册》，覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。
获取方式：点“在看”，关注公众号并回复 Java 领取，更多内容陆续奉上。</p>
如果文章有帮助，请阅读它，转发它。
感谢您的支持哟（*^__^*）。
