Node.js GPS设备跟踪性能考虑

Question

使用 node.js 作为 TCP 服务器，我将管理相对大量的 GPS 设备（~3000个设备），作为第一步仅会将收到的数据存储在数据库中，但即使在这个阶段，我想象中也会有一些性能问题困扰着我，我希望在它们给我带来麻烦之前就能够解决掉它们。

1- 查看使用像 java 或 ruby 这样的语言编写类似服务器的代码时，我看到了以下的代码：

java

Thread serverThread = new Thread(() -> {
  System.out.println("Listening to server port 9000");
  while (true) {
    try {
      Socket socket = serverSocket.accept();
  ...

ruby

 require 'socket'
   server = TCPServer.new ("127.0.0.1",8080)
   loop do
     Thread.start(server.accept) do |client|
     ...

看起来他们为每个连接到tcp服务器的设备（socket）提供了单独的线程？由于node.js是单线程且异步操作，我应该担心传入的连接或者像以下简单方法一样能满足大量同时连接的需求吗？

net.createServer(function(device) {
  device.on('data', function(data) {
    // parse data
    // store in database
  });
});

2 - 我应该使用连接池来限制数据库连接吗？因为数据库还会从GIS和监控的另一侧查询，所以连接池的大小应该是多少呢？

3 - 在这样的系统中，我如何受益于缓存（例如使用redis）？

如果有人能为这些想法提供一些启示，那就太好了。我也很愿意听听您在实现这样的系统时可能经历或了解到的任何其他性能方面的想法。谢谢。

- dNitro

---

完全是一个侧面的问题，但为什么要使用套接字而不是定期的HTTP请求呢？ - Gergo

@Festo，我只能在TCP层与GPS设备通信，在这一层中我肯定应该使用套接字来与设备通信，在HTTP服务器中我可以使用周期性请求，但由于数据将是实时的，所以我也会使用套接字。 - dNitro

@dNitro，针对技术需求，你最终如何结束使用某些东西？因为我计划通过他们的移动设备跟踪现场销售用户。 - Hunt

@dNitro，你是否已经使用Node.js跟踪GPS设备？如果是，请分享一下。 - Jayavel

Answer 1

1. 从您列出的选项中选择，我会说NodeJS实际上是您情况下更好的选择，因为它不像其他两个选项那样每个连接使用一个线程。线程通常是给定计算机上有限的资源。Java和Ruby确实拥有“事件驱动”服务器，如果您想进行苹果对苹果的比较，这些服务器值得一看。Java 和Ruby。

2. 如果您想获得有关连接池的建议，我认为您需要更多地介绍您打算使用的数据库。然而，如果设置连接很耗费成本，重复使用连接将是一个好主意。最好能够配置池的最小和最大大小。最终要使用的正确大小是一个测试问题。

3. 我认为在此系统中缓存的好处很少，因为您主要是在写数据。如果数据很有价值，您会希望将其写入磁盘而不是内存。另一方面，如果您有客户端正在读取所收集的数据，可能在类似Redis 的东西中缓存它们的读取是个好主意。

- Frank Wilson

---

谢谢您的回答，我真的需要一些对这些选择的信心，而您的回答给了我这种信心，所以我认为我可以完成第一阶段。Java和Ruby事件驱动服务器很好，但我会选择node.js，因为我更有经验。实际上，我将使用Postgres作为数据库，因为在下一个阶段中我需要处理GIS。我打算使用Redis作为缓存层，所以我认为当我们决定如何查询数据库以及哪些数据应该随时可用时，我会将其与http服务器一起实现。 - dNitro

Answer 2

I'm sure you're aware, but this sounds like you're trying to prematurely optimize your application here.

1- Node being event-driven and non-blocking makes it a perfect candidate for holding a large number of open socket connections, no need for forking per connection. As always though, make sure your application is properly clustered. I was able to hold ~100k open TCP sockets on a dirt cheap laptop. If the number of device you need to support ever grows beyond that, just scale accordingly.

2- I saw you were planning on using postgres. Pools are always a good thing.

3- Caching is useful for 'hot' data. Stuff that gets queried a lot, and therefore having it in memory or inside redis (in-memory storage) makes these data lookups faster and removes strain on the system. In your case, if you just need to get certain chunks of data, for analytics or for more causal use, I would recommend spark or solr as opposed to a plain caching layer. It's also going to be much cheaper and easier to maintain.

- NodeNodeNode

---

很好的观点。我有一些ElasticSearch的经验，但似乎像Spark或Solr这样的工具在这个领域更加成熟；所以我会关注它们。我想“过早优化”是我一开始想要的表达，但找不到它。非常感谢您与我分享您的经验。非常感谢。 - dNitro