SQL सर्वर में कई श्रमिकों के लिए FIFO कतार तालिका


15

मैं निम्नलिखित स्टैक्वॅवरफ्लो प्रश्न का उत्तर देने का प्रयास कर रहा था:

कुछ भोले जवाब पोस्ट करने के बाद, मुझे लगा कि मैं अपना पैसा लगाऊंगा और मेरा मुंह वास्तव में परीक्षण करेगा मैं जिस परिदृश्य का सुझाव दे रहा था, उसका कर रहा था, यह सुनिश्चित करने के लिए कि मैं एक जंगली हंस पीछा पर ओपी को नहीं भेज रहा था। ठीक है, यह जितना मैंने सोचा था उससे कहीं अधिक कठिन है (किसी को आश्चर्य नहीं, मुझे यकीन है)।

यहाँ मैंने क्या कोशिश की है और इसके बारे में सोचा है:

  • पहले मैंने कोशिश की कि एक व्युत्पन्न तालिका के अंदर, एक ORDER के साथ एक शीर्ष 1 अद्यतन का उपयोग करके ROWLOCK, READPAST। यह गतिरोध उत्पन्न करता है और वस्तुओं को ऑर्डर से बाहर भी संसाधित करता है। यह संभव के रूप में FIFO के करीब होना चाहिए, उन त्रुटियों को रोकना जो एक ही पंक्ति को एक से अधिक बार संसाधित करने के प्रयास की आवश्यकता होती है।

  • मैं तो एक चर में वांछित अगले QueueID का चयन करने की कोशिश की, के विभिन्न संयोजनों का उपयोग कर READPAST, UPDLOCK, HOLDLOCK, और ROWLOCKविशेष रूप से अद्यतन के लिए पंक्ति है कि सत्र से रक्षा करने के लिए। मैंने जिन विविध रूपों की कोशिश की, उन्हीं मुद्दों से पहले और साथ ही, कुछ विशेष संयोजनों के साथ READPAST, शिकायत की:

    आप केवल READPAST लॉक को READ COMMITTED या REPEATABLE READ आइसोलेशन स्तरों में निर्दिष्ट कर सकते हैं।

    यह भ्रमित करने वाला था क्योंकि यह READ COMMITTED था । मैं इसमें पहले भी दौड़ चुका हूं और यह निराशाजनक है।

  • जब से मैंने यह सवाल लिखना शुरू किया, रेमस रुसानी ने इस सवाल का नया जवाब पोस्ट किया। मैंने उनके लिंक किए गए लेख को पढ़ा और देखा कि वह विनाशकारी पठन का उपयोग कर रहे हैं, क्योंकि उन्होंने अपने जवाब में कहा था कि "वेब कॉल की अवधि के लिए ताले पर पकड़ना वास्तविक रूप से संभव नहीं है।" हॉट स्पॉट और पेज के बारे में उनका लेख क्या कहता है इसे पढ़ने के बाद लॉक करने के लिए किसी भी अपडेट या डिलीट को करने की आवश्यकता होती है, मुझे डर है कि अगर मैं जो खोज रहा हूं उसे करने के लिए मैं सही लॉक को भी काम करने में सक्षम था, तो यह स्केलेबल नहीं होगा और हो सकता है बड़े पैमाने पर संगामिति संभाल नहीं है।

अभी मुझे यकीन नहीं है कि मुझे कहाँ जाना है। क्या यह सच है कि पंक्ति को संसाधित करते समय ताले को बनाए रखा जा सकता है (भले ही यह उच्च tps या बड़े पैमाने पर संगामिति का समर्थन नहीं करता)? मुझे किसकी याद आ रही है?

इस उम्मीद में कि लोग मुझसे ज्यादा स्मार्ट हैं और मुझसे ज्यादा अनुभवी लोग मदद कर सकते हैं, नीचे टेस्ट स्क्रिप्ट है जो मैं इस्तेमाल कर रहा था। इसे वापस शीर्ष 1 अद्यतन विधि में बदल दिया गया है, लेकिन मैंने दूसरी विधि छोड़ दी है, टिप्पणी की है, यदि आप भी उस का पता लगाना चाहते हैं।

इनमें से प्रत्येक को एक अलग सत्र में पेस्ट करें, सत्र 1 चलाएं, फिर जल्दी से अन्य सभी को। लगभग 50 सेकंड में परीक्षण खत्म हो जाएगा। प्रत्येक सत्र के संदेशों को देखें कि उसने क्या काम किया (या यह कैसे विफल हुआ)। पहले सत्र में एक स्नैपशॉट के साथ एक पंक्तियों को दिखाया जाएगा, जो कि एक बार मौजूद तालों के विवरण और दूसरी-संसाधित कतार की वस्तुओं का विवरण देगा। यह कभी-कभी काम करता है, और अन्य समय बिल्कुल भी काम नहीं करता है।

सत्र 1

/* Session 1: Setup and control - Run this session first, then immediately run all other sessions */
IF Object_ID('dbo.Queue', 'U') IS NULL
   CREATE TABLE dbo.Queue (
      QueueID int identity(1,1) NOT NULL,
      StatusID int NOT NULL,
      QueuedDate datetime CONSTRAINT DF_Queue_QueuedDate DEFAULT (GetDate()),
      CONSTRAINT PK_Queue PRIMARY KEY CLUSTERED (QueuedDate, QueueID)
   );

IF Object_ID('dbo.QueueHistory', 'U') IS NULL
   CREATE TABLE dbo.QueueHistory (
      HistoryDate datetime NOT NULL,
      QueueID int NOT NULL
   );

IF Object_ID('dbo.LockHistory', 'U') IS NULL
   CREATE TABLE dbo.LockHistory (
      HistoryDate datetime NOT NULL,
      ResourceType varchar(100),
      RequestMode varchar(100),
      RequestStatus varchar(100),
      ResourceDescription varchar(200),
      ResourceAssociatedEntityID varchar(200)
   );

IF Object_ID('dbo.StartTime', 'U') IS NULL
   CREATE TABLE dbo.StartTime (
      StartTime datetime NOT NULL
   );

SET NOCOUNT ON;

IF (SELECT Count(*) FROM dbo.Queue) < 10000 BEGIN
   TRUNCATE TABLE dbo.Queue;

   WITH A (N) AS (SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1),
   B (N) AS (SELECT 1 FROM A Z, A I, A P),
   C (N) AS (SELECT Row_Number() OVER (ORDER BY (SELECT 1)) FROM B O, B W)
   INSERT dbo.Queue (StatusID, QueuedDate)
   SELECT 1, DateAdd(millisecond, C.N * 3, GetDate() - '00:05:00')
   FROM C
   WHERE C.N <= 10000;
END;

TRUNCATE TABLE dbo.StartTime;
INSERT dbo.StartTime SELECT GetDate() + '00:00:15'; -- or however long it takes you to go run the other sessions
GO
TRUNCATE TABLE dbo.QueueHistory;
SET NOCOUNT ON;

DECLARE
   @Time varchar(8),
   @Now datetime;
SELECT @Time = Convert(varchar(8), StartTime, 114)
FROM dbo.StartTime;
WAITFOR TIME @Time;

DECLARE @i int,
@QueueID int;
SET @i = 1;
WHILE @i <= 33 BEGIN
   SET @Now  = GetDate();
   INSERT dbo.QueueHistory
   SELECT
      @Now,
      QueueID
   FROM
      dbo.Queue Q WITH (NOLOCK)
   WHERE
      Q.StatusID <> 1;

   INSERT dbo.LockHistory
   SELECT
      @Now,
      L.resource_type,
      L.request_mode,
      L.request_status,
      L.resource_description,
      L.resource_associated_entity_id
   FROM
      sys.dm_tran_current_transaction T
      INNER JOIN sys.dm_tran_locks L
         ON L.request_owner_id = T.transaction_id;
   WAITFOR DELAY '00:00:01';
   SET @i = @i + 1;
END;

WITH Cols AS (
   SELECT *, Row_Number() OVER (PARTITION BY HistoryDate ORDER BY QueueID) Col
   FROM dbo.QueueHistory
), P AS (
   SELECT *
   FROM
      Cols
      PIVOT (Max(QueueID) FOR Col IN ([1], [2], [3], [4], [5], [6], [7], [8])) P
)
SELECT L.*, P.[1], P.[2], P.[3], P.[4], P.[5], P.[6], P.[7], P.[8]
FROM
   dbo.LockHistory L
   FULL JOIN P
      ON L.HistoryDate = P.HistoryDate

/* Clean up afterward
DROP TABLE dbo.StartTime;
DROP TABLE dbo.LockHistory;
DROP TABLE dbo.QueueHistory;
DROP TABLE dbo.Queue;
*/

सत्र २

/* Session 2: Simulate an application instance holding a row locked for a long period, and eventually abandoning it. */
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SET NOCOUNT ON;
SET XACT_ABORT ON;

DECLARE
   @QueueID int,
   @Time varchar(8);
SELECT @Time = Convert(varchar(8), StartTime + '0:00:01', 114)
FROM dbo.StartTime;
WAITFOR TIME @Time;
BEGIN TRAN;

--SET @QueueID = (
--   SELECT TOP 1 QueueID
--   FROM dbo.Queue WITH (READPAST, UPDLOCK)
--   WHERE StatusID = 1 -- ready
--   ORDER BY QueuedDate, QueueID
--);

--UPDATE dbo.Queue
--SET StatusID = 2 -- in process
----OUTPUT Inserted.*
--WHERE QueueID = @QueueID;

SET @QueueID = NULL;
UPDATE Q
SET Q.StatusID = 1, @QueueID = Q.QueueID
FROM (
   SELECT TOP 1 *
   FROM dbo.Queue WITH (ROWLOCK, READPAST)
   WHERE StatusID = 1
   ORDER BY QueuedDate, QueueID
) Q

PRINT @QueueID;

WAITFOR DELAY '00:00:20'; -- Release it partway through the test

ROLLBACK TRAN; -- Simulate client disconnecting

सत्र ३

/* Session 3: Run a near-continuous series of "failed" queue processing. */
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SET XACT_ABORT ON;
SET NOCOUNT ON;
DECLARE
   @QueueID int,
   @EndDate datetime,
   @NextDate datetime,
   @Time varchar(8);

SELECT
   @EndDate = StartTime + '0:00:33',
   @Time = Convert(varchar(8), StartTime, 114)
FROM dbo.StartTime;

WAITFOR TIME @Time;

WHILE GetDate() < @EndDate BEGIN
   BEGIN TRAN;

   --SET @QueueID = (
   --   SELECT TOP 1 QueueID
   --   FROM dbo.Queue WITH (READPAST, UPDLOCK)
   --   WHERE StatusID = 1 -- ready
   --   ORDER BY QueuedDate, QueueID
   --);

   --UPDATE dbo.Queue
   --SET StatusID = 2 -- in process
   ----OUTPUT Inserted.*
   --WHERE QueueID = @QueueID;

   SET @QueueID = NULL;
   UPDATE Q
   SET Q.StatusID = 1, @QueueID = Q.QueueID
   FROM (
      SELECT TOP 1 *
      FROM dbo.Queue WITH (ROWLOCK, READPAST)
      WHERE StatusID = 1
      ORDER BY QueuedDate, QueueID
   ) Q

   PRINT @QueueID;

   SET @NextDate = GetDate() + '00:00:00.015';
   WHILE GetDate() < @NextDate SET NOCOUNT ON;
   ROLLBACK TRAN;
END

सत्र 4 और ऊपर - जितने चाहें

/* Session 4: "Process" the queue normally, one every second for 30 seconds. */
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SET XACT_ABORT ON;
SET NOCOUNT ON;

DECLARE @Time varchar(8);
SELECT @Time = Convert(varchar(8), StartTime, 114)
FROM dbo.StartTime;
WAITFOR TIME @Time;

DECLARE @i int,
@QueueID int;
SET @i = 1;
WHILE @i <= 30 BEGIN
   BEGIN TRAN;

   --SET @QueueID = (
   --   SELECT TOP 1 QueueID
   --   FROM dbo.Queue WITH (READPAST, UPDLOCK)
   --   WHERE StatusID = 1 -- ready
   --   ORDER BY QueuedDate, QueueID
   --);

   --UPDATE dbo.Queue
   --SET StatusID = 2 -- in process
   --WHERE QueueID = @QueueID;

   SET @QueueID = NULL;
   UPDATE Q
   SET Q.StatusID = 1, @QueueID = Q.QueueID
   FROM (
      SELECT TOP 1 *
      FROM dbo.Queue WITH (ROWLOCK, READPAST)
      WHERE StatusID = 1
      ORDER BY QueuedDate, QueueID
   ) Q

   PRINT @QueueID;
   WAITFOR DELAY '00:00:01'
   SET @i = @i + 1;
   DELETE dbo.Queue
   WHERE QueueID = @QueueID;   
   COMMIT TRAN;
END

2
लिंक किए गए लेख में वर्णित कतारों को प्रति सेकंड सैकड़ों या कम हजारों ऑपरेशन किए जा सकते हैं। हॉट स्पॉट विवाद मुद्दे केवल उच्च स्तर पर प्रासंगिक हैं। ऐसी शमन रणनीतियां हैं जो उच्च अंत प्रणाली पर उच्च थ्रूपुट प्राप्त कर सकती हैं, जो प्रति सेकंड हजारों में जा रही हैं, लेकिन उन मितलीकरणों को सावधानीपूर्वक मूल्यांकन की आवश्यकता होती है और SQLCAT पर्यवेक्षण के तहत तैनात किए जाते हैं ।
रेमुस जानु

एक दिलचस्प शिकन यह है कि READPAST, UPDLOCK, ROWLOCKक्यूयूहिस्टोरिन तालिका में डेटा कैप्चर करने के लिए मेरी स्क्रिप्ट के साथ कुछ भी नहीं कर रहा है। मुझे आश्चर्य है कि क्या क्योंकि StatusID प्रतिबद्ध नहीं है? यह WITH (NOLOCK)बहुत सैद्धांतिक रूप से काम करना चाहिए ... का उपयोग कर रहा है और यह पहले काम किया था! मुझे यकीन नहीं है कि यह अब क्यों काम नहीं कर रहा है, लेकिन यह शायद एक और सीखने का अनुभव है।
एरिक

क्या आप अपने कोड को सबसे छोटे नमूने को कम कर सकते हैं जो गतिरोध और अन्य समस्याओं को प्रदर्शित करता है जिन्हें आप हल करने की कोशिश कर रहे हैं?
निक चामास

@ मैं कोड को कम करने की कोशिश करूँगा। आपकी अन्य टिप्पणियों के बारे में, एक पहचान स्तंभ है जो संकुल अनुक्रमणिका का हिस्सा है और तिथि के बाद आदेश दिया गया है। मैं एक "विनाशकारी रीड" (OUTPUT के साथ DELETE) का मनोरंजन करने के लिए काफी इच्छुक हूं, लेकिन पंक्ति में स्वचालित रूप से प्रसंस्करण के लिए वापस आने के लिए, आवेदन की विफलता के मामले में, आवश्यकताओं में से एक था। तो मेरा सवाल यहाँ है कि क्या यह संभव है।
एरिक

विध्वंसक पढ़ने के दृष्टिकोण की कोशिश करें और जहां से आवश्यक हो, वहां से एक अलग तालिका में हटा दी गई वस्तुओं को रखें। यदि वह इसे ठीक कर देता है, तो आप इस पुनः प्रक्रिया प्रक्रिया को सुचारू रूप से करने में निवेश कर सकते हैं।
निक चामास

जवाबों:


10

आपको ठीक 3 लॉक संकेत चाहिए

  • READPAST
  • UPDLOCK
  • चप्पू-आंकड़ा

मैंने इसका उत्तर SO पर पहले दिया था: /programming/939831/sql-server-process-queue-race-condition/940001#940001

जैसा कि रेमस कहता है, सर्विस ब्रोकर का उपयोग करना अच्छा है लेकिन ये संकेत काम करते हैं

आइसोलेशन स्तर के बारे में आपकी त्रुटि का मतलब आमतौर पर प्रतिकृति या NOLOCK शामिल है।


मेरी स्क्रिप्ट पर उन संकेतों का उपयोग करना जैसा कि ऊपर दिया गया है गतिरोध और क्रम से बाहर की प्रक्रिया। ( UPDATE SET ... FROM (SELECT TOP 1 ... FROM ... ORDER BY ...)) क्या इसका मतलब यह है कि लॉक रखने के साथ मेरा अद्यतन पैटर्न काम नहीं कर सकता है? इसके अलावा, जिस क्षण आप अपने READPASTसाथ जोड़ते HOLDLOCKहैं वह त्रुटि हो जाती है। इस सर्वर पर कोई प्रतिकृति नहीं है और अलगाव स्तर READ COMMITTED है।
एरिक

2
@ErikE - जैसे ही आप तालिका को क्वेरी करते हैं कि तालिका कैसे संरचित है, महत्वपूर्ण है। जिस तालिका को आप एक कतार के रूप में उपयोग कर रहे हैं, उसे डीक्यू ऑर्डर में क्लस्टर किया जाना चाहिए , ताकि अगले आइटम को डिलीट किया जा सके । यह महत्वपूर्ण है। अपने कोड को ऊपर उठाते हुए, मुझे कोई भी संकुल अनुक्रमित परिभाषित नहीं दिखता है।
निक चम्मास

@ यह पूरी तरह से प्रचलित समझ में आता है और मुझे नहीं पता कि मैंने इसके बारे में क्यों नहीं सोचा। मैंने उचित पीके बाधा जोड़ी (और ऊपर मेरी स्क्रिप्ट को अद्यतन किया), और फिर भी गतिरोध मिला। हालाँकि, आइटम अब सही क्रम में संसाधित किए गए थे, डेडलॉक किए गए आइटम के लिए पुन: प्रसंस्करण को रोकते हुए।
एरिक

@ एरिक - 1. आपकी कतार में केवल पंक्तिबद्ध आइटम होना चाहिए। हटाए जाने और आइटम का मतलब इसे कतार तालिका से हटा देना चाहिए। मैं देख रहा हूं कि आप StatusIDकिसी आइटम को हटाने के बजाय अपडेट कर रहे हैं । क्या वो सही है? 2. आपका छल आदेश असंदिग्ध होना चाहिए। यदि आप आइटमों की कतार बना रहे हैं GETDATE(), तो उच्च मात्रा में यह बहुत संभावना है कि एक ही समय में कई आइटम समान रूप से dequeuing के लिए पात्र होंगे। इससे गतिरोध पैदा होगा। मैं सुझाव देता हूं कि IDENTITYएक असम्बद्ध डैक्यू ऑर्डर की गारंटी देने के लिए क्लस्टर इंडेक्स में जोड़ें।
निक चामास

1

SQL सर्वर रिलेशनल डेटा संग्रहीत करने के लिए बहुत अच्छा काम करता है। एक नौकरी कतार के लिए के रूप में, यह बहुत अच्छा नहीं है। यह लेख देखें जो MySQL के लिए लिखा गया है, लेकिन यह यहां भी लागू हो सकता है। https://blog.engineyard.com/2011/5-subtle-ways-youre-using-mysql-as-a-queue-and-why-itll-bite-you


धन्यवाद, एरिक। प्रश्न के अपने मूल उत्तर में, मैं SQL सर्वर सेवा ब्रोकर का उपयोग करने का सुझाव दे रहा था क्योंकि मैं इस तथ्य के लिए जानता हूं कि तालिका-जैसा-कतार विधि वास्तव में वैसा नहीं है जैसा डेटाबेस के लिए बनाया गया था। लेकिन मुझे लगता है कि यह अच्छी सिफारिश नहीं है क्योंकि एसबी वास्तव में केवल संदेशों के लिए है। डेटाबेस में डाले गए डेटा के एसीआईडी ​​गुण इसे (अब) उपयोग करने की कोशिश करने के लिए एक बहुत ही आकर्षक कंटेनर बनाते हैं। क्या आप एक वैकल्पिक, कम लागत वाले उत्पाद का सुझाव दे सकते हैं जो एक सामान्य कतार के रूप में कार्य करेगा? और वापस किया जा सकता है, आदि आदि?
एरिक

8
लेख कतार प्रसंस्करण में एक ज्ञात गिरावट का दोषी है: राज्य और घटनाओं को एक ही तालिका में मिलाएं (वास्तव में यदि आप लेख टिप्पणियों को देखेंगे तो आप देखेंगे कि मैंने कुछ समय पहले इस पर आपत्ति जताई थी)। इस समस्या का विशिष्ट लक्षण 'प्रोसेस्ड / प्रोसेसिंग' फील्ड है। घटनाओं के साथ राज्य का मेल (यानी। राज्य तालिका बनाने 'कतार') विशाल आकार के लिए 'कतार' बढ़ रहा में परिणाम (के बाद से राज्य तालिका है कतार)। सच्ची कतार में घटनाओं को अलग करने से एक कतार बन जाती है जो 'नालियां' (खाली हो जाती है) और यह बहुत बेहतर व्यवहार करती है।
रेमस रूसु

क्या लेख में यह सुझाव नहीं दिया गया है कि: कतार तालिका में केवल काम के लिए तैयार आइटम हैं?
एरिक

2
@ एरिक: आप इस पैराग्राफ का उल्लेख कर रहे हैं, है ना? एक-मेज-टेबल सिंड्रोम से बचना भी वास्तव में आसान है। नए ईमेल के लिए बस एक अलग तालिका बनाएं, और जब आप उन्हें संसाधित कर रहे हों, तो उन्हें दीर्घकालिक भंडारण में सम्मिलित करें और फिर उन्हें कतार तालिका से हटा दें। नए ईमेल की तालिका आम तौर पर बहुत छोटी रहेगी और इस पर परिचालन तेज होगा । इसके साथ मेरा झगड़ा यह है कि 'बड़ी कतारों' के मुद्दे के लिए एक समाधान के रूप में दिया जाता है । यह सिफारिश लेख के उद्घाटन में होनी चाहिए थी, एक बुनियादी मुद्दा है।
रेमस रूसु जूल

यदि आप राज्य बनाम घटना के स्पष्ट पृथक्करण में सोचना शुरू करते हैं तो आप बहुत आसान रास्ता शुरू करते हैं। यहां तक कि recomemendation ऊपर में बदल जाएगा में नए ईमेल डालने emailsमेज और में new_emailsकतार। प्रसंस्करण new_emailsकतार को प्रदूषित करता है और emailsतालिका में स्थिति को अद्यतन करता है । यह कतारों में यात्रा कर रहे 'वसा' राज्य की समस्या से भी बचता है। अगर हम वितरित प्रसंस्करण और संचार के साथ सच्ची कतारों के बारे में बात करेंगे , (उदाहरण के लिए एसएसबी) तो चीजें और अधिक जटिल हो जाती हैं क्योंकि साझा राज्य परेशान प्रणालियों में समस्याग्रस्त है।
रेमस रुसानु
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.