Apache Ignite设计最佳实践咨询：基于JBoss EAP7三层应用场景

Hey there! As someone who’s helped a few teams integrate Ignite into JBoss-based apps, let’s walk through the best design practices tailored to your scenario—three-tier (DAO/Service/Presentation) on JBoss EAP7, 50 static reference tables with ~50k total records. Since these are static (rarely updated, I assume), we can lean hard into read performance optimizations.

First, let’s get the caching strategy right for your static tables:

• Use Read-Only Caches: Since these tables don’t change often, configure your Ignite caches with readThrough=false and writeThrough=false to eliminate unnecessary DB round-trips. Set cacheMode=LOCAL if each JBoss instance can hold the full dataset (50k records is tiny—this is totally feasible), or REPLICATED if you want a copy on every node for maximum availability.
• Preload Data on Startup: Instead of lazy-loading (which causes first-request delays), preload all static data into Ignite when your app or Ignite cluster starts. You can do this via:

  IgniteCache<Integer, ReferenceData> cache = ignite.getOrCreateCache("reference-data-cache");
  // Load all records from DB and put into cache
  List<ReferenceData> data = referenceDataDao.findAll();
  data.forEach(item -> cache.put(item.getId(), item));
  

• Group Related Tables into Cache Groups: If your app frequently joins certain static tables (e.g., country + state + city), put them into the same cache group. This lets Ignite colocate data and optimize join performance without hitting the database.

Avoid classloading conflicts and ensure smooth integration:

• Use Ignite Client Mode: Deploy Ignite as a separate cluster (not embedded in JBoss) and connect your JBoss app via the Ignite Java client. This keeps JBoss’s runtime clean and avoids conflicts between Ignite’s dependencies and JBoss’s internal libraries.
• Configure JBoss Module for Ignite: If you prefer shared dependencies, package Ignite’s core jars into a JBoss module. Define a module.xml in JBOSS_HOME/modules/system/layers/base/org/apache/ignite/main with the necessary dependencies, then add a dependency to your app’s jboss-deployment-structure.xml:

  <jboss-deployment-structure>
      <deployment>
          <dependencies>
              <module name="org.apache.ignite" />
          </dependencies>
      </deployment>
  </jboss-deployment-structure>
  

• Handle Logging Compatibility: Ignite uses SLF4J by default. Configure JBoss to route Ignite logs to its own logging system by adding the SLF4J bridge module dependency in your deployment.

Minimize changes to your existing DAO layer while adding cache support:

• Add a Cache Abstraction Layer: Create a wrapper or decorator around your existing DAOs that checks the Ignite cache first before hitting the database. For example:

  public class CachedReferenceDataDao implements ReferenceDataDao {
      private final ReferenceDataDao delegate;
      private final IgniteCache<Integer, ReferenceData> cache;
  
      // Constructor injection
      public CachedReferenceDataDao(ReferenceDataDao delegate, IgniteCache<Integer, ReferenceData> cache) {
          this.delegate = delegate;
          this.cache = cache;
      }
  
      @Override
      public ReferenceData findById(Integer id) {
          // Check cache first
          ReferenceData data = cache.get(id);
          if (data == null) {
              // Fallback to DB and populate cache
              data = delegate.findById(id);
              if (data != null) {
                  cache.put(id, data);
              }
          }
          return data;
      }
  }
  

• Avoid Over-Caching Simple Queries: For small lookup tables (e.g., status codes with 10 records), it’s fine to cache the entire collection instead of individual entries. This reduces cache key overhead.
• Batch Loads for Initialization: When preloading, use batch putAll() instead of individual put() calls to improve performance.

Make sure your upper layers leverage the cache effectively:

• Pass Cache Hits Upwards: Ensure service methods return cached data directly without unnecessary processing. If your service layer does aggregations on static data, consider precomputing those aggregations and storing them in Ignite as well (e.g., a cached count of active countries).
• Use Ignite SQL for Cross-Table Queries: If your app needs to join multiple static tables, use Ignite’s SQL capabilities instead of querying the database. Define your cache’s SQL schema with QueryEntity annotations or XML config, then run queries like:

  SqlFieldsQuery query = new SqlFieldsQuery(
      "SELECT c.name, s.name FROM Country c JOIN State s ON c.id = s.country_id WHERE c.code = ?"
  ).setArgs("US");
  List<List<?>> results = cache.query(query).getAll();
  

• Don’t Expose Cache Details to Presentation Layer: Keep cache logic encapsulated in DAO/Service layers. The presentation layer should interact with services as usual—no need to modify it for Ignite integration.

Keep your Ignite deployment running smoothly:

• Cache Invalidation on Data Updates: Since these are static tables, when you do need to update data (e.g., a new country is added), implement a manual cache refresh mechanism. This could be a JMX endpoint, a REST API, or a scheduled job that reloads the affected tables into Ignite.
• Monitor Cache Hit Ratio: Track Ignite’s cache hit ratio via its built-in metrics (or JMX) to ensure the cache is actually reducing DB load. A hit ratio above 95% is ideal for static data.
• Test for Classloading Conflicts: Run your app in a staging environment first to catch conflicts (e.g., Ignite’s version of a library conflicting with JBoss’s). Use JBoss’s module isolation to resolve any issues.

内容的提问来源于stack exchange，提问作者Sanjay