Cygnus 版本是 0.8.2,我正在使用来自 FI-Ware Lab 内的 FI-Ware 实例的 Cosmos 公共实例。
我有 8 个将更新推送到 IDAS 的传感器设备。有些更新每秒一次,有些更新每 5 秒一次,平均每秒更新 8,35 次左右。我创建了对 Orion(0.22 版)的订阅,以向 Cygnus 发送 ONCHANGE 通知。
Cygnus 配置为将数据持久化到 Cosmos、Mongo 和 MySQL。我使用了标准配置,其中 1 个源(http-source)、3 个通道(hdfs-channel mysql-channel mongo-channel)和 3 个接收器(hdfs-sink mysql-sink mongo-sink)。
mysql-sink 和 mongo-sink 近乎实时地持久化数据。但是,hdfs-sink 真的很慢,每秒只有大约 1,65 个事件。由于 http-source 每秒接收大约 8,35 个事件,hdfs-channel 很快就满了,您会收到日志文件的警告。
time=2015-07-30T13:39:02.168CEST | lvl=WARN | trans=1438256043-345-0000002417 | function=doPost | comp=Cygnus | msg=org.apache.flume.source.http.HTTPSource$FlumeHTTPServlet[203] : Error appending event to channel. Channel might be full. Consider increasing the channel capacity or make sure the sinks perform faster.
org.apache.flume.ChannelException: Unable to put batch on required channel: org.apache.flume.channel.MemoryChannel{name: hdfs-channel}
at org.apache.flume.channel.ChannelProcessor.processEventBatch(ChannelProcessor.java:200)
at org.apache.flume.source.http.HTTPSource$FlumeHTTPServlet.doPost(HTTPSource.java:201)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:814)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:945)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
Caused by: org.apache.flume.ChannelException: Space for commit to queue couldn't be acquired Sinks are likely not keeping up with sources, or the buffer size is too tight
at org.apache.flume.channel.MemoryChannel$MemoryTransaction.doCommit(MemoryChannel.java:128)
at org.apache.flume.channel.BasicTransactionSemantics.commit(BasicTransactionSemantics.java:151)
at org.apache.flume.channel.ChannelProcessor.processEventBatch(ChannelProcessor.java:192)
... 16 more
副作用是,如果 http-source 无法将通知注入 hdfs-channel,它也不会将其注入 mysql-channel 和 mongo-channel,并且该通知完全丢失。它没有坚持到任何地方。
您可以通过启动 3 个单独的 Cygnuse(一个用于 Cosmos,一个用于 MySQL,一个用于 MongoDB)来部分规避该问题,这些 Cygnuse 具有不同的 http-source 端口、不同的管理接口端口并为每个 Cygnus 添加订阅。MySQL 和 MongoDB 的持久化不受 hdfs-channel 变满的影响,但 Cosmos 的持久化仍然存在问题。添加更多 hdfs-sinks 可能会对我们的 8 个传感器设备起到作用,但如果您添加更多传感器设备或者它们发送更多更新,您只是在推迟问题。
这两个问题有点无关,但我还是在问......
问题一:坚持宇宙真的有那么慢吗?
我知道与持久化到本地数据库相比,幕后发生了很多事情,并且我们正在使用资源有限的 Cosmos 的公共实例,但仍然如此。它甚至意味着要以这种方式与实时数据一起使用(我们的 8 传感器设备测试甚至相当适中)?当然,也可以创建一个接收器,将数据推送到一个文件,然后将一个简单的文件上传到 Cosmos,但这有点麻烦。我想没有这样的文件接收器可用?
问题2:如果通知不能注入到hdfs-channel(我猜是任何通道),它是否也没有被添加到其他通道并且被完全丢弃?