Jeskson文档-微服务分布式系统架构

物联网cassandra

2020/1/1

点击勘误issues (opens new window)，哪吒感谢大家的阅读

# 物联网cassandra

cassandraDao 的类，主要用于与 Cassandra 数据库进行交互，特别是与存储 协议相关消息的表进行操作。它实现了插入数据、查询数据、以及表的创建等功能。具体来说，它主要用于处理和存储设备 发送的消息，并将这些消息保存在 Cassandra 数据库中。

# 使用场景：

设备消息存储：该类用于存储设备 发送的消息数据。它将设备 消息内容等信息存储到 Cassandra 数据库中，便于后续查询和分析。

数据备份：除了主表外，还会将数据备份到备用的 Cassandra 数据库中，以确保数据的可靠性。

系统日志：对于存储的每条数据，都会进行日志记录，这有助于后续的调试、分析和监控。

# 总结：

Cassandra 数据库交互的 DAO（数据访问对象），它负责存储、查询和管理 协议相关的设备消息数据。它支持自动创建表、分页查询、数据插入、以及备份等功能，确保了数据的高可用性和可查询性。

# 优化建议：

# 日志记录优化：

当前日志记录较为简单，且没有在关键操作和异常处理中进行详细记录。需要更细致的日志记录，尤其是在异常和操作成功时。

# 避免静态集合存储表名：

checkTableExistSet 和 checkBackupTableExistSet 是静态集合，可能导致不同实例间数据共享。如果每个实例需要独立检查表的创建状态，应将其改为实例变量。

# 时间格式化的优化：

SimpleDateFormat 在多线程环境下是非线程安全的，可以使用 ThreadLocal<SimpleDateFormat> 保证线程安全。

# 避免重复的表创建逻辑：

checkTableExist 和 checkBackupTableExist 的逻辑重复，且不够灵活。可以提取成一个通用方法来避免重复代码。

# 数据库操作的异常处理：

Cassandra 的操作可能会失败，但当前代码未对数据库操作失败进行详细的异常处理，建议加强异常捕获和日志记录。

# 数据插入方法的优化：

insertAsync 方法中使用了多个 insertAsync 调用，这会在插入时产生并发请求。可以考虑引入事务或批量插入的方式来优化性能。

状态变化监测

差异对比

优化方案：

  • 使用 Map 或 List 存储字段和值，以减少代码重复。
  • 提取字段对比到一个通用方法中。
  • 使用 StringJoiner 或 StringBuilder 来替代 StringBuffer，并避免每次修改时都重新创建 StringBuffer。

优化点总结：

避免重复代码和不必要的复杂性：

  1. 避免在 handle 方法内部重新创建线程池和任务队列。
  2. 优化线程池的创建，避免不必要的线程池重建。
  3. 简化异常处理，不需要捕获所有异常，明确处理需要捕获的类型。

代码优化：

  1. 使用 ExecutorService 管理线程池，避免频繁使用 submit 方法。
  2. xxxHandleBlockingQueue 不应该是 static，因为它依赖于实例。
  3. 在多线程环境中，要保证线程安全性，尽量避免在多个地方对同一资源进行操作。
  4. 可以使用 Optional 或更明确的空值检查来减少不必要的 null 检查。

日志优化：

减少重复日志的记录，避免日志过多导致性能瓶颈。

性能优化：

增加一个xxx队列的积压阈值限制，避免过度积压导致线程池任务过载。

物联网设备