Node.js中如何读写文件指定位置、实现文件锁并避免竞态条件？

Hey there! Let's walk through solving your problem—since you're building a high-performance persistent tree in Node.js (using array indexes instead of pointers, like C), we need to nail two key things: efficient random I/O for 32-byte items, and reliable locking to avoid race conditions without killing performance for your millions of operations.

Randomly Reading/Writing 32-Byte Items #

Node.js's fs module has everything you need for random file access—you just need to work with a persistent file descriptor and calculate the correct offset for each 32-byte item.

First, open your file once (don't open/close it for every operation—this kills performance) and keep the file descriptor (fd) handy:

const fs = require('fs').promises;
let fileDescriptor;

// Initialize the file (call this once at startup)
async function initPersistentStore(filePath) {
  // Open in read-write mode; create if it doesn't exist
  fileDescriptor = await fs.open(filePath, 'r+');
  // Optional: Pre-allocate space if you know the maximum number of items
  // await fileDescriptor.ftruncate(maxItems * 32);
}

Then, for reading a specific index's 32-byte item:

async function readTreeItem(index) {
  const buffer = Buffer.alloc(32);
  const offset = index * 32;
  
  const { bytesRead } = await fileDescriptor.read(
    buffer, // Buffer to fill
    0,      // Offset within the buffer to write to
    32,     // Number of bytes to read
    offset  // Position in the file to read from
  );

  if (bytesRead !== 32) {
    throw new Error(`Failed to read full item at index ${index}`);
  }
  return buffer;
}

For writing an item to a specific index:

async function writeTreeItem(index, dataBuffer) {
  if (dataBuffer.length !== 32) {
    throw new Error('Tree items must be exactly 32 bytes');
  }
  const offset = index * 32;

  const { bytesWritten } = await fileDescriptor.write(
    dataBuffer, // Buffer to write
    0,          // Offset within the buffer to read from
    32,         // Number of bytes to write
    offset      // Position in the file to write to
  );

  if (bytesWritten !== 32) {
    throw new Error(`Failed to write full item at index ${index}`);
  }
}

Avoiding Race Conditions with Locking #

You're right that fs.open doesn't block other processes or async calls—we need two types of locking depending on your use case:

1. Same-Process Async Locking (For Internal Race Conditions) #

Since Node.js runs on a single event loop, async operations can still overlap and cause race conditions (e.g., two concurrent tree updates trying to write the same nodes). A simple in-memory mutex or read-write lock will solve this with near-zero overhead.

Here's a lightweight read-write lock implementation (great for read-heavy tree workloads):

let activeReads = 0;
let writeLockActive = false;
const readQueue = [];
const writeQueue = [];

// Wrap read operations with this to allow concurrent reads
async function withReadLock(operation) {
  return new Promise((resolve, reject) => {
    if (writeLockActive) {
      readQueue.push({ op: operation, resolve, reject });
    } else {
      activeReads++;
      operation()
        .then(resolve)
        .catch(reject)
        .finally(() => {
          activeReads--;
          if (activeReads === 0 && writeQueue.length > 0) {
            processWriteQueue();
          }
        });
    }
  });
}

// Wrap write/update operations with this to ensure exclusive access
async function withWriteLock(operation) {
  return new Promise((resolve, reject) => {
    if (writeLockActive || activeReads > 0) {
      writeQueue.push({ op: operation, resolve, reject });
    } else {
      writeLockActive = true;
      operation()
        .then(resolve)
        .catch(reject)
        .finally(() => {
          writeLockActive = false;
          if (readQueue.length > 0) {
            processReadQueue();
          } else if (writeQueue.length > 0) {
            processWriteQueue();
          }
        });
    }
  });
}

function processReadQueue() {
  while (readQueue.length > 0 && !writeLockActive) {
    const { op, resolve, reject } = readQueue.shift();
    activeReads++;
    op()
      .then(resolve)
      .catch(reject)
      .finally(() => {
        activeReads--;
        if (activeReads === 0 && writeQueue.length > 0) {
          processWriteQueue();
        }
      });
  }
}

function processWriteQueue() {
  if (!writeLockActive && activeReads === 0 && writeQueue.length > 0) {
    const { op, resolve, reject } = writeQueue.shift();
    writeLockActive = true;
    op()
      .then(resolve)
      .catch(reject)
      .finally(() => {
        writeLockActive = false;
        if (readQueue.length > 0) {
          processReadQueue();
        } else if (writeQueue.length > 0) {
          processWriteQueue();
        }
      });
  }
}

Use it like this for your tree operations:

// Safe concurrent read
async function getTreeNode(index) {
  return withReadLock(() => readTreeItem(index));
}

// Safe exclusive update (multiple file ops in one transaction)
async function updateTreeNodes(node1Index, node2Index, updatedNode1, updatedNode2) {
  return withWriteLock(async () => {
    // Read existing nodes (if needed for your update logic)
    const oldNode1 = await readTreeItem(node1Index);
    const oldNode2 = await readTreeItem(node2Index);
    
    // Your tree update logic here...
    
    // Write back updated nodes
    await writeTreeItem(node1Index, updatedNode1);
    await writeTreeItem(node2Index, updatedNode2);
    
    return { oldNode1, oldNode2 };
  });
}

2. Cross-Process Locking (If Multiple Node Processes Access the File) #

If you have multiple Node.js processes working with the same tree file, you need a filesystem-level lock. Node.js 18+ supports fs.lock/fs.unlock for cross-platform locking, or you can use fs.flock (POSIX systems only):

// Acquire an exclusive lock for write operations
async function acquireExclusiveLock() {
  await fileDescriptor.lock(
    fs.constants.LOCK_EX, // Exclusive lock (blocks others)
    0,                    // Start of file
    Infinity              // Lock entire file
  );
}

// Release the lock
async function releaseLock() {
  await fileDescriptor.unlock(0, Infinity);
}

// Use it in your update logic
async function crossProcessTreeUpdate() {
  await acquireExclusiveLock();
  try {
    // Your multi-step file operations here
    await readTreeItem(100);
    await writeTreeItem(100, updatedBuffer);
  } finally {
    // Always release the lock even if something fails
    await releaseLock();
  }
}

Note: LOCK_EX is exclusive (for writes), while LOCK_SH is a shared lock (for concurrent reads). Use shared locks for read operations to keep performance high.

Performance Optimizations for High-Volume Operations #

Since you're dealing with hundreds of millions of file operations, every small optimization adds up:

• Reuse Buffers: Instead of creating a new Buffer.alloc(32) for every read/write, maintain a pool of pre-allocated buffers to reduce garbage collection overhead.
• Batch I/O: Use fs.readv and fs.writev to read/write multiple items in a single system call—this cuts down on kernel context switches.
• Use O_DIRECT: If your filesystem supports it, open the file with fs.constants.O_DIRECT to bypass the OS page cache. This is great for random I/O where cache hit rates are low, as it avoids wasting memory on unused cache.
• SSD Storage: Random I/O performance is drastically better on SSDs compared to HDDs—this is non-negotiable for your workload.
• Minimize Lock Scope: Keep the code inside withWriteLock as lean as possible—only wrap the necessary file operations, not your entire tree logic.

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