A page content scheduling and front-end rendering control method and system based on static constraint mapping and multi-factor rule engine

Abstract

The application discloses a page content scheduling and front-end rendering control method and system based on static constraint mapping and a multi-factor rule engine. The application realizes resource isolation by loading a static read-only mapping table and storing it in a memory HashMap; a resource pool is constructed by using Redis ZSet; local multi-factor scoring is realized by using a DSL rule engine; when the resource pool is empty, an idle state is returned, and display:none is used in the front end to realize hidden hiding without occupying space; periodic quota atomic resetting is realized by using a message queue and a database transaction; and temporary weighted queuing is realized by using Redis ZSet score injection. The application realizes high-concurrency conflict-free scheduling, zero-AI-cost personalization and front-end zero-jitter rendering, and is suitable for content display scenes with high stability requirements such as APP and Web.

Description

[0001] Invention Title: A Method and System for Page Content Scheduling and Front-End Rendering Control Based on Static Constraint Mapping and Multi-Factor Rule Engine Technical Field

[0002] This invention relates to the field of computer application technology, specifically to client-side interface rendering control, server-side resource scheduling, real-time data computation and high-concurrency processing technology, and particularly to a system and method for achieving conflict-free scheduling, rule-based personalized recommendations, and stable front-end layout control in idle states under preset fixed display positions and static mapping constraints. Background Technology

[0003] In content display and resource scheduling scenarios of internet applications, mobile apps, and web platforms, existing technologies generally suffer from the following technical deficiencies:

[0004] 1) Multiple contents compete for a fixed display position, resulting in frequent scheduling conflicts. This requires complex mechanisms such as distributed locks, polling, and dynamic bidding, which leads to high system overhead, poor stability, and easy delays and anomalies under high concurrency.

[0005] 2) Personalized recommendations typically rely on third-party AI models, machine learning services, or external recommendation interfaces, resulting in high system coupling, high call costs, high response latency, and weak autonomy and controllability.

[0006] 3) When there is no valid content in the display area, the front-end interface generally uses white space, placeholders or dynamic reflow, which can easily cause page shaking, layout misalignment and rendering offset, seriously affecting user experience and interface stability.

[0007] 4) Periodic rights (such as monthly quotas and frequency limits) rely on manual maintenance, offline scripts or scheduled batch processing for updates, which makes it difficult to achieve atomic, event-driven, and cluster-consistent automatic resets, and is prone to problems such as data inconsistency, over-issuance, and missed issuance.

[0008] 5) Temporary heating, short-term weighting and other queue-jumping mechanisms often intrude into the main scheduling process, disrupt the original sorting logic, occupy fixed resource slots, and affect the simplicity and stability of the overall system.

[0009] Existing technologies cannot simultaneously solve five major technical problems under the same architecture: conflict-free scheduling, low-cost personalization, absolutely stable front-end layout, automated periodic rights and interests, and temporary weighting without intrusion. Summary of the Invention

[0010] This invention aims to overcome the shortcomings of existing technologies and provide a page content scheduling and front-end rendering control method and system based on static constraint mapping and multi-factor rule engine. It eliminates resource competition at the architectural level, achieves personalized recommendations with zero AI cost through a local rule engine, achieves front-end jitter-free rendering through status identifiers, and realizes automatic management of periodic rights and temporary weighted non-intrusive queue jumping.

[0011] The technical solution adopted by this invention to solve its technical problem is:

[0012] A Page Content Scheduling Method Based on Static Constraint Mapping and Multi-Factor Rule Engine

[0013] S100 loads a static read-only mapping table of content types—resource bits—from the configuration file at system startup. This table is stored as an in-memory HashMap structure and cannot be modified during runtime, thus achieving architecture-level resource isolation.

[0014] S200 receives content creation requests, queries a HashMap based on the content type, uniquely binds the content to the corresponding resource pool, and stores it in a Redis sorted set.

[0015] In S300, when a user accesses a page, the interface layer obtains the user tag from the request header, reads the Redis resource pool based on the resource ID, and filters valid content to build a candidate set.

[0016] S400's rule engine reads configurable DSL rules and calculates scores in parallel across five dimensions: content quality score, type weight, user matching degree, historical conversion rate, and time decay factor. The overall score is calculated using a multiplicative model.

[0017] S500: The scheduler selects the highest-scoring content and returns it; if the Redis resource pool is empty, it returns a JSON structure {status:"idle"}.

[0018] S600: The front-end parses the response. If it is in an idle state, it sets the container's display:none through DOM manipulation and removes it from the document flow to ensure layout stability.

[0019] S700's distributed scheduled task publishes a MONTHLY_RESET event on the 1st of each month, which is synchronized to all service nodes via a message queue to atomically reset quotas using database transactions.

[0020] S800, the temporary weighted task injects temporary weights through ZSet scores, which only affects the sorting, does not occupy fixed resource slots, and automatically expires upon expiration.

[0021] A Page Content Scheduling System Based on Static Constraint Mapping and Multi-Factor Rule Engine

[0022] The system includes:

[0023] Static mapping management module: Uses ConcurrentHashMap to store read-only mappings, supporting startup loading and hot updates.

[0024] Content binding and resource pool module: Implements resource pooling storage based on Redis ZSet, with isolation by resource bit.

[0025] Multi-factor rule engine module: Built-in DSL rule parser, supports configurable scoring formulas.

[0026] Scheduling decision module: Implements high-concurrency optimal scheduling based on lock-free programming.

[0027] Front-end stable rendering module: Uses display:none to hide idle containers so they do not occupy space.

[0028] Automatic periodic rights management module: Quota reset is implemented based on message queues and distributed transactions.

[0029] Temporary weighting module: Implements short-term queue jumping based on Redis ZSet scores.

[0030] Effect

[0031] 1) No conflict at the architecture level: Static mapping + resource pooling eliminates concurrency competition at the source and eliminates the need for distributed locks.

[0032] 2) Zero AI cost: Pure local DSL rule engine, does not rely on third-party models, and has a millisecond-level response time.

[0033] 3) Zero front-end jitter: Idle containers are removed from the document flow, ensuring an absolutely stable page layout.

[0034] 4) Event-driven automation: Periodic quotas are updated atomically and consistently across the cluster via message queues.

[0035] 5) Non-intrusive temporary weighting: Based on ZSet score injection, it does not occupy slots or intrude on the main process.

[0036] 6) Highly scalable: Mapping relationships and scoring rules are configurable and support hot updates. Attached Figure Description

[0037] Figure 1. Overall system architecture diagram of the present invention

[0038] Figure 2. Flowchart of the scheduling and scoring process of this invention

[0039] Figure 3. Flowchart of front-end rendering and idle control in this invention Detailed Implementation

[0040] Example 1: Static Mapping (HashMap)

[0041] System startup loads YAML configuration:

[0042] Plain Text

[0043] slot_mapping:

[0044] typeA: [slot1]

[0045] typeB: [slot2,slot3]

[0046] typeC: [slot4]

[0047] Store in a ConcurrentHashMap, which is read-only during runtime.

[0048] Example 2: Multi-Factor Rule Engine (DSL Formula)

[0049] Scoring rules:

[0050] score = quality * weight * match * convert * time

[0051] All calculations are performed locally, with no remote calls.

[0052] Example 3: Front-end Idle Control

[0053] Front-end code logic:

[0054] Plain Text

[0055] if (res.status === 'idle') {

[0056] document.getElementById('slot2').style.display = 'none';

[0057] }

[0058] Example 4: Periodic Automatic Reset

[0059] The system sends message queue events via a scheduled task. After the service listens for the event, it performs the following operations:

[0060] The `resetQuota()` method, annotated with `@Transactional`, performs a database update operation.

[0061] An example statement is: update campaign set quota=10 where type='monthly'.

[0062] Example 5: Temporary Weighting

[0063] Execute Redis commands:

[0064] Plain Text

[0065] ZINCRBY slot2:contents 100 "campaign_123"

[0066] It will automatically recover after 10 minutes.

Claims

1. A method for page content scheduling and front-end rendering control, characterized in that, include: When the system starts, it loads a static read-only mapping table of content types and display resource positions and stores it as an in-memory HashMap structure; Receive content creation requests and bind the content to the corresponding Redis resource pool according to the mapping relationship; When a user visits, user tags are obtained and valid content is filtered from the resource pool to form a candidate set; The DSL rule engine calculates multi-dimensional comprehensive scores in parallel. Return the highest-scoring content; if the resource pool is empty, return an idle status indicator. The front-end sets `display:none` to hide the display container to prevent it from occupying space based on its idle state. Atomic reset of periodic quotas is achieved through message queues and database transactions; Implement temporary weighted queue jumping by injecting Redis ZSet scores.

2. The method according to claim 1, characterized in that, The static read-only mapping table is stored using ConcurrentHashMap and cannot be modified during runtime.

3. The method according to claim 1, characterized in that, The resource pool is implemented based on Redis sorted sets (ZSet).

4. The method according to claim 1, characterized in that, The multi-factor scoring uses a configurable DSL formula, is calculated locally, and does not rely on third-party AI.

5. The method according to claim 1, characterized in that, Setting `display:none` on the front end removes the container from the document flow, preventing page layout jitter.

6. The method according to claim 1, characterized in that, Periodic quotas are atomic and cluster-consistently updated through distributed transactions.

7. The method according to claim 1, characterized in that, Temporary weighting is achieved by modifying the ZSet score, without occupying fixed resource bits.

8. A system for implementing the method of any one of claims 1-7, characterized in that, include: Static mapping management module; Content binding and resource pool module; DSL rules engine module; Lock-free scheduling decision module; Front-end stable rendering module; Automatic management module for periodic equity; Temporary weighting module.

Images