در این مطلب، ویدئو استفاده از Redis با پایتون برای تجزیه و تحلیل دادههای COVID-19 – RedisConf 2020 با زیرنویس فارسی را برای دانلود قرار داده ام. شما میتوانید با پرداخت 15 هزار تومان ، این ویدیو به علاوه تمامی فیلم های سایت را دانلود کنید.اکثر فیلم های سایت به زبان انگلیسی می باشند. این ویدئو دارای زیرنویس فارسی ترجمه شده توسط هوش مصنوعی می باشد که میتوانید نمونه ای از آن را در قسمت پایانی این مطلب مشاهده کنید.
مدت زمان فیلم: 00:23:13
تصاویر این ویدئو:
قسمتی از زیرنویس این فیلم:
00:00:03,950 –> 00:00:07,020
سلام نام من دیمیتری پولیاکوف اسکی است و
2
00:00:07,020 –> 00:00:08,550
از حضور در این
3
00:00:08,550 –> 00:00:11,190
کنفرانس مجازی در گذشته هیجان زده هستم، زمانی
4
00:00:11,190 –> 00:00:13,049
که نویسندگان را ارائه کردم، پروازی
5
00:00:13,049 –> 00:00:13,620
6
00:00:13,620 –> 00:00:16,079
به سانفرانسیسکو داشتم، اما اکنون می توانم
7
00:00:16,079 –> 00:00:17,820
سهام را مستقیماً از خانه خود در سیاتل انجام دهم.
8
00:00:17,820 –> 00:00:20,670
ارائه بر اساس ویرایشگر گفتگو است
9
00:00:20,670 –> 00:00:22,980
که سیاتل ردیس
10
00:00:22,980 –> 00:00:25,380
تنها چند ماه پیش قبل از شیوع ویروس کرونا مطمئن
11
00:00:25,380 –> 00:00:28,140
بود و آن بحث
12
00:00:28,140 –> 00:00:31,320
مبتنی بر استفاده از Redis برای استخراج api عمومی github بود.
13
00:00:31,320 –> 00:00:33,780
14
00:00:33,780 –> 00:00:36,300
15
00:00:36,300 –> 00:00:37,739
دادهها قبل از اینکه من جمعآوریهای اضافی انجام دهم
16
00:00:37,739 –> 00:00:41,520
و سپس همهگیری ویروس کرونا
17
00:00:41,520 –> 00:00:43,590
شیوع پیدا کند و من در
18
00:00:43,590 –> 00:00:45,030
خانه نشستهام و سعی میکنم همه این
19
00:00:45,030 –> 00:00:48,329
دادهها را بفهمم و اعتراف میکنم که
20
00:00:48,329 –> 00:00:49,829
دیدن تعداد قربانیان در حال افزایش
21
00:00:49,829 –> 00:00:51,000
برای مشاهده تعداد افرادی که مبتلا شدهاند
22
00:00:51,000 –> 00:00:54,120
ناراحتکننده بود. در سرتاسر جهان چیزی که من میخواستم
23
00:00:54,120 –> 00:00:56,160
ابزاری بود که به من کمک میکرد دادههای او را برای مکانهای خاص تجزیه و تحلیل کنم، بهعنوان
24
00:00:56,160 –> 00:00:58,410
مثال،
25
00:00:58,410 –> 00:01:00,480
شهرستان کینگ واشنگتن که سیاتل در آن
26
00:01:00,480 –> 00:01:03,000
قرار دارد و همچنین برای دیدن دادههای
27
00:01:03,000 –> 00:01:05,069
روزهای خاصی که میخواستم. برای اینکه بدانم چه تعداد از
28
00:01:05,069 –> 00:01:07,500
افراد جدید دیروز بیمار شدند یا
29
00:01:07,500 –> 00:01:10,170
در هفته گذشته فوت کردند، نتوانستم چنین
30
00:01:10,170 –> 00:01:15,360
ابزاری را پیدا کنم، بنابراین خودم آن را ساختم،
31
00:01:15,360 –> 00:01:17,729
توسعه دهنده ارشد نرم افزار در Oracle cloud
32
00:01:17,729 –> 00:01:19,830
هستم، می توانید وبلاگ من را در توییتر دنبال کنید یا
33
00:01:19,830 –> 00:01:21,479
بررسی کنید کدی که من به عنوان بخشی
34
00:01:21,479 –> 00:01:25,049
از این ارائه استفاده کردم، روشی که
35
00:01:25,049 –> 00:01:27,000
در مورد آن درست فکر میکنم این است که یک ابزار چند منظوره
36
00:01:27,000 –> 00:01:29,850
است، بنابراین یک چاقوی ارتشی است و
37
00:01:29,850 –> 00:01:32,220
در موارد مختلف خوب است و من از آن
38
00:01:32,220 –> 00:01:34,140
برای اهداف مختلف استفاده میکنم و به عنوان حافظه پنهان
39
00:01:34,140 –> 00:01:37,049
به عنوان کار استفاده میکنم. صف برای کاهش دسترسی به api من
40
00:01:37,049 –> 00:01:39,090
فقط استفاده از اطلاعات جلسه کاربر فروشگاه
41
00:01:39,090 –> 00:01:42,600
و غیره در این
42
00:01:42,600 –> 00:01:44,460
ارائه من بر روی استفاده از Redis
43
00:01:44,460 –> 00:01:47,070
برای مدیریت قفل توزیع شده با استفاده از
44
00:01:47,070 –> 00:01:49,680
Redis یک صف کار است و استفاده از Redis به عنوان
45
00:01:49,680 –> 00:01:54,119
یک پایگاه داده برای ذخیره داده ها در
46
00:01:54,119 –> 00:01:55,590
معماری کلی تمرکز می کنم. برنامه
47
00:01:55,590 –> 00:01:58,049
این است که من چندین کانتینر ایجاد کردم،
48
00:01:58,049 –> 00:01:59,579
یک کانتینر وجود دارد، مجموعه ای از کانتینرها وجود دارد
49
00:01:59,579 –> 00:02:02,369
که زمانبندی ها را اجرا می کنند و قفل را با
50
00:02:02,369 –> 00:02:05,250
Redis می خوانند، تضمین می کند که تنها برنامه ریزی شده
51
00:02:05,250 –> 00:02:07,129
من می توانم آن را در هر زمان معین اجرا
52
00:02:07,129 –> 00:02:09,449
کنم که یک مدیریت قفل توزیع شده است. بخش ement به
53
00:02:09,449 –> 00:02:12,090
طور جداگانه دارای کارگران در
54
00:02:12,090 –> 00:02:13,590
کانتینرهای مختلف است که ما
55
00:02:13,590 –> 00:02:16,290
از یک صف دوباره به وجود میآوریم و آخرین من
56
00:02:16,290 –> 00:02:18,780
سرورهای وب دارم که دادهها را ارائه میدهند و به
57
00:02:18,780 –> 00:02:21,840
سادگی دادهها را از پایگاه Stata آماده میخوانند، ممکن است
58
00:02:21,840 –> 00:02:24,239
بپرسید چرا چنین پیچیدگی یک
59
00:02:24,239 –> 00:02:26,040
برنامه بسیار ساده است و شما کاملاً درست میگویید که
60
00:02:26,040 –> 00:02:27,900
میتوانم داشته باشم. یک اسکریپت ساده
61
00:02:27,900 –> 00:02:30,330
نوشت و از طریق crontab در یک
62
00:02:30,330 –> 00:02:33,269
کانتینر یا یک ماشین مجازی اجرا کرد، اما
63
00:02:33,269 –> 00:02:35,099
میخواستم نشان دهم که چگونه میتوان از Redis برای
64
00:02:35,099 –> 00:02:37,650
مقیاسبندی واقعی چیزها استفاده کرد، به عنوان مثال اگر
65
00:02:37,650 –> 00:02:39,629
به کارگران بیشتری نیاز دارم، میتوانم چندین کانتینر را راهاندازی
66
00:02:39,629 –> 00:02:42,269
کنم اگر در سرورهای وب خود باشم یا
67
00:02:42,269 –> 00:02:44,069
کانتینرهای وب من میتوانم این ظرفیت
68
00:02:44,069 –> 00:02:46,950
را نیز افزایش دهم و این ارائه همچنین
69
00:02:46,950 –> 00:02:48,750
بر اساس کاری است که من روی سیستمهای واقعی انجام دادم،
70
00:02:48,750 –> 00:02:51,390
جایی که ما با
71
00:02:51,390 –> 00:02:53,790
حجم بسیار بیشتری از دادهها سروکار داشتیم، چندین
72
00:02:53,790 –> 00:02:55,680
صف شغلی با اولویتهای مختلف
73
00:02:55,680 –> 00:02:57,540
داشتیم و فیدهای زیادی در روز اجرا میکردیم.
74
00:02:57,540 –> 00:02:59,519
در حال پردازش مقادیر وسیعی از دادهها
75
00:02:59,519 –> 00:03:01,769
هستیم و با تغییر تقاضای ما مجبور به افزایش و کاهش مقیاس شدیم،
76
00:03:01,769 –> 00:03:05,549
اجازه دهید
77
00:03:05,549 –> 00:03:07,650
محیط توسعهدهندهای را که من از docker استفاده میکنم بررسی کنیم و docker
78
00:03:07,650 –> 00:03:10,470
compose docker compose اجازه میدهد من برای
79
00:03:10,470 –> 00:03:12,720
شروع و متوقف کردن کانتینرهای جداگانه
80
00:03:12,720 –> 00:03:16,170
به طور همزمان به عنوان مثال در اینجا من به یک
81
00:03:16,170 –> 00:03:19,739
پرونده پزشک اشاره کرده ام و پورت
82
00:03:19,739 –> 00:03:22,950
5000 را که کانتینر وب من است برای ساخت این برنامه در معرض نمایش قرار می دهم.
83
00:03:22,950 –> 00:03:24,569
84
00:03:24,569 –> 00:03:27,060
85
00:03:27,060 –> 00:03:30,269
86
00:03:30,269 –> 00:03:34,380
متغیر کانتینر نوع وب و استفاده از برخی
87
00:03:34,380 –> 00:03:36,150
و خواندن برخی
88
00:03:36,150 –> 00:03:39,120
از متغیرهای محیطی رایج از فایلی که در
89
00:03:39,120 –> 00:03:41,970
اینجا مهم نیست، سپس من یک ظرف
90
00:03:41,970 –> 00:03:44,489
به نام worker Mora تعیین کنید
91
00:03:44,489 –> 00:03:47,810
type container worker من همان کد را در آنجا مستقر می
92
00:03:47,810 –> 00:03:51,000
کنم اما هیچ پورتی را در معرض نمایش قرار نمی دهم و سپس
93
00:03:51,000 –> 00:03:53,910
دارم یک زمانبندی که میگوید
94
00:03:53,910 –> 00:03:56,250
متغیر محیطی نوع کانتینر زمانبندیکننده آخرین است،
95
00:03:56,250 –> 00:03:58,500
اما نه کم اهمیت، من آخرین نسخه ردیس را اجرا
96
00:03:58,500 –> 00:04:01,769
97
00:04:01,769 –> 00:04:03,660
98
00:04:03,660 –> 00:04:06,599
99
00:04:06,599 –> 00:04:09,599
100
00:04:09,599 –> 00:04:11,579
میکنم. چند
101
00:04:11,579 –> 00:04:14,669
متغیر محیطی من کدم را کپی میکنم، وابستگیها را نصب
102
00:04:14,669 –> 00:04:16,880
میکنم و نقطه ورود من را
103
00:04:16,880 –> 00:04:19,380
در یک فایل داکر مشخص میکنم،
104
00:04:19,380 –> 00:04:22,140
زمانی شروع میشود که ادامه ainer شروع میشود و در
105
00:04:22,140 –> 00:04:23,880
یک سیستم واقعی احتمالاً میخواهید از
106
00:04:23,880 –> 00:04:26,099
چیزی مانند run it یا systemd استفاده کنید و
107
00:04:26,099 –> 00:04:26,970
108
00:04:26,970 –> 00:04:28,890
آن را به یک دیمون تبدیل کنید، اما به دلیل سادگی،
109
00:04:28,890 –> 00:04:31,760
من با یک اسکریپت bash در اینجا گیر کردم،
110
00:04:31,760 –> 00:04:34,230
اینجا جایی است که منطق کسب و کار است
111
00:04:34,230 –> 00:04:36,540
که کنترل میکند کدام فرآیند در آن اجرا شود.
112
00:04:36,540 –> 00:04:38,370
113
00:04:38,370 –> 00:04:41,070
اگر
114
00:04:41,070 –> 00:04:44,160
متغیر نوع کانتینر
115
00:04:44,160 –> 00:04:47,220
116
00:04:47,220 –> 00:04:49,590
وب باشد، از کدام کانتینر استفاده میکنم، بسته به اینکه
117
00:04:49,590 –> 00:04:51,650
برنامهنویس را به صورت محلی اجرا میکنم یا در حال تولید
118
00:04:51,650 –> 00:04:54,570
Container type
119
00:04:54,570 –> 00:04:57,210
worker I start worker با استفاده از RQ
120
00:04:57,210 –> 00:05:00,390
worker library / q یک کتابخانه Python است
121
00:05:00,390 –> 00:05:02,010
که به من کمک می کند تا با ثبت به عنوان
122
00:05:02,010 –> 00:05:04,860
یک صف شغل ادغام کنم و این کارگر RQ
123
00:05:04,860 –> 00:05:08,040
یک لیست Redis را تماشا می کند که به عنوان یک
124
00:05:08,040 –> 00:05:10,410
صف کار استفاده می شود و از آنجا مشاغل را می گیرد. در صورت
125
00:05:10,410 –> 00:05:12,930
لزوم و آخرین زمانی که من یک
126
00:05:12,930 –> 00:05:15,270
کیت فلاسک را اجرا می کنم، زمانبندی خودم را
127
00:05:15,270 –> 00:05:17,970
با استفاده از فلاسک CLI که نوع ظرف زمانبندی را مشخص می کند، اجرا می کنم،
128
00:05:17,970 –> 00:05:22,770
ابتدا اجازه دهید
129
00:05:22,770 –> 00:05:24,630
در مورد مدیریت قفل توزیع شده یا توزیع شده صحبت
130
00:05:24,630 –> 00:05:27,630
کنیم. نیاز به
131
00:05:27,630 –> 00:05:30,270
مدیریت قفل توزیع کننده دارید چرا از
132
00:05:30,270 –> 00:05:32,790
چیزی ساده به عنوان crontab استفاده نکنید هر
133
00:05:32,790 –> 00:05:35,180
crontab کاملاً مناسب یک ابزار عالی است
134
00:05:35,180 –> 00:05:38,460
که من از آن استفاده کرده ام پروژه های زیادی وجود دارد
135
00:05:38,460 –> 00:05:40,650
اما محدودیت هایی دارد به عنوان
136
00:05:40,650 –> 00:05:42,780
مثال می تواند یک نقطه شکست باشد که
137
00:05:42,780 –> 00:05:45,300
اگر فرآیند ما با فرآیند تماس برقرار کند یا
138
00:05:45,300 –> 00:05:46,830
سرور در حال اجرا cron جدول خراب
139
00:05:46,830 –> 00:05:49,620
می شود هیچ چیزی اجرا نمی شود و به طور
140
00:05:49,620 –> 00:05:52,590
جداگانه می تواند یک مشکل مقیاس پذیری باشد همانطور که
141
00:05:52,590 –> 00:05:55,200
ما کارهای بیشتری می نویسیم می توانیم
142
00:05:55,200 –> 00:05:56,669
به محدودیت های کاری که یک سرور می تواند
143
00:05:56,669 –> 00:06:00,000
انجام دهد
144
00:06:00,000 –> 00:06:01,770
برسیم.
145
00:06:01,770 –> 00:06:03,570
زمانبندی کار یا اجرای کار،
146
00:06:03,570 –> 00:06:06,570
بنابراین زمانبندی crontab به
147
00:06:06,570 –> 00:06:08,910
سادگی کار را در یک صف قرار میدهد و سپس چندین
148
00:06:08,910 –> 00:06:11,010
کارگر که روی سرورهای مختلف مینویسند میتوانند
149
00:06:11,010 –> 00:06:13,080
کارهای خود را از صف گرفته و
150
00:06:13,080 –> 00:06:15,450
به صورت موازی آنها را اجرا کنند، اما
151
00:06:15,450 –> 00:06:18,120
یک نقطه از شکست را حل نمیکند و اگر کارهای ما
152
00:06:18,120 –> 00:06:20,190
ضعیف هستند، مثلاً
153
00:06:20,190 –> 00:06:22,800
میتوانیم گزارشهایی تولید کنیم که فقط میتوانیم دو زمانبندی را اجرا کنیم
154
00:06:22,800 –> 00:06:25,470
و همه کارها را دو بار انجام دهیم، اما برخی از
155
00:06:25,470 –> 00:06:28,020
کارها مهمتر از آن هستند، مثلاً
156
00:06:28,020 –> 00:06:29,280
اگر ما اجرای یک فرآیند صورتحساب و
157
00:06:29,280 –> 00:06:31,320
دریافت هزینه اشتراک ماهانه از کاربران
158
00:06:31,320 –> 00:06:34,020
برای دسترسی، ما نمیخواهیم آن
159
00:06:34,020 –> 00:06:36,479
مشاغل را دو بار اجرا کنیم یا کاربران ناراضی زیادی
160
00:06:36,479 –> 00:06:39,030
خواهیم داشت و همچنین نمیخواهیم
161
00:06:39,030 –> 00:06:40,710
آن مشاغل را اجرا
162
00:06:40,710 –> 00:06:42,630
کنیم، زیرا در غیر این صورت تعداد زیادی کار خواهیم داشت.
163
00:06:42,630 –> 00:06:45,780
مدیران کسب و کار ناراضی این
164
00:06:45,780 –> 00:06:47,460
جایی است که مدیریت قفل توزیع
165
00:06:47,460 –> 00:06:50,280
شده به ما اجازه می دهد تا
166
00:06:50,280 –> 00:06:53,190
فرآیند خاصی را بر روی هر سروری اجرا کنیم که به ما افزونگی می دهد،
167
00:06:53,190 –> 00:06:55,680
اما تضمین می کند که
168
00:06:55,680 –> 00:06:58,260
فرآیند فقط بر روی یک سرور اجرا شود و
169
00:06:58,260 –> 00:07:00,150
آن ویژگی قفل قرمز شماره یک است که
170
00:07:00,150 –> 00:07:02,580
در هر زمان مشخصی وجود دارد. زمانی که فقط
171
00:07:02,580 –> 00:07:05,460
یک فرآیند می تواند اجرا شود دومین
172
00:07:05,460 –> 00:07:08,730
مسئله مهم این است که ما می خواهیم از بن بست جلوگیری کنیم، به
173
00:07:08,730 –> 00:07:11,340
عنوان مثال اگر یک فرآیند شروع به یک
174
00:07:11,340 –> 00:07:13,080
قفل در یک منبع مشترک می کند و سپس
175
00:07:13,080 –> 00:07:15,540
قبل از اینکه بتواند قفل را به درستی آزاد کند خراب می شود
176
00:07:15,540 –> 00:07:17,610
، هیچ یک از فرآیندهای
177
00:07:17,610 –> 00:07:20,310
دیگر اجرا نمی شوند تا زمانی که به صورت دستی مداخله کنیم و
178
00:07:20,310 –> 00:07:23,820
Retta آن را با TTL حل می کند
179
00:07:23,820 –> 00:07:26,670
و سوم ما می خواهیم اطمینان حاصل کنیم که
180
00:07:26,670 –> 00:07:28,980
تحمل خطای خاصی وجود دارد و نمی
181
00:07:28,980 –> 00:07:31,050
خواهیم مکانیزم قفل عربی-عربی ما
182
00:07:31,050 –> 00:07:32,610
یکپارچه شود. نقطه شکست به
183
00:07:32,610 –> 00:07:35,040
خودی خود به عنوان مثال در گذشته
184
00:07:35,040 –> 00:07:37,290
گاهی اوقات از قفل ساده مبتنی بر فایل استفاده
185
00:07:37,290 –> 00:07:39,990
میکردم، یک حجم را روی دو
186
00:07:39,990 –> 00:07:42,180
سرور مختلف ایجاد میکردم و هنگامی که فرآیند من
187
00:07:42,180 –> 00:07:44,970
شروع میشود، روی یک فایل
188
00:07:44,970 –> 00:07:48,180
در حجم مشترک قفل میشود، کار میکند، اما نقطه
189
00:07:48,180 –> 00:07:49,950
ضعف آن این است که که اگر به هر دلیلی
190
00:07:49,950 –> 00:07:52,440
سرور من دسترسی به آن ولوم
191
00:07:52,440 –> 00:07:55,620
مانت را از دست بدهد، نمی تواند قفل را بدست آورد، نمی تواند
192
00:07:55,620 –> 00:07:57,630
اجرا شود یا اگر ولوم مونت به طور کامل از بین برود،
193
00:07:57,630 –> 00:07:59,760
هیچ یک از سرویس های من
194
00:07:59,760 –> 00:08:01,950
نمی توانند قفل بگیرند، بنابراین روش
195
00:08:01,950 –> 00:08:03,960
Redis و الگوریتم قفل خواندن این مشکل را حل می کند.
196
00:08:03,960 –> 00:08:06,750
مشکل با ایجاد یک
197
00:08:06,750 –> 00:08:08,310
مکانیسم قفل است که در آن فرآیند باید
198
00:08:08,310 –> 00:08:10,350
قفل و اکثر گرههای Redis را به دست آورد،
199
00:08:10,350 –> 00:08:12,920
بنابراین اگر یکی از آنها مشکل داشت،
200
00:08:12,920 –> 00:08:15,120
امیدواریم سرورهای Redis دیگر همچنان فعال
201
00:08:15,120 –> 00:08:15,990
باشند،
202
00:08:15,990 –> 00:08:17,730
بنابراین میتوانید درباره قفل خواندن در Redis i اطلاعات بیشتری کسب کنید
203
00:08:17,730 –> 00:08:22,500
. وب سایت /o در Redis
204
00:08:22,500 –> 00:08:24,990
الگوریتم قفل خواندن تاریخ داده قفل قرمز
205
00:08:24,990 –> 00:08:26,880
بسیار ساده به نظر می رسد فقط یک رشته است که
206
00:08:26,880 –> 00:08:28,950
یک کلید را مشخص می کنید در مورد من
207
00:08:28,950 –> 00:08:33,090
آن را وارد کردن داده نامیدم و گفتم وقتی کد
208
00:08:33,090 –> 00:08:35,490
ایجاد می شود یک قفل همچنین یک کلید منحصربهفرد ایجاد میکند
209
00:08:35,490 –> 00:08:37,860
که بعداً برای باز کردن قفل استفاده میشود
210
00:08:37,860 –> 00:08:40,320
که به این معنی است که آن را حذف کنید.
211
00:08:40,320 –> 00:08:46,980
212
00:08:46,980 –> 00:08:49,650
213
00:08:49,650 –> 00:08:51,270
214
00:08:51,270 –> 00:08:53,790
اندازه
215
00:08:53,790 –> 00:08:59,550
و همچنین من در اینجا از یک
216
00:08:59,550 –> 00:09:01,470
کتابخانه Python به نام AP Scheduler استفاده می کنم،
217
00:09:01,470 –> 00:09:03,000
برای اهداف این
218
00:09:03,000 –> 00:09:04,410
ارائه مهم نیست، اما شما می
219
00:09:04,410 –> 00:09:06,680
توانید جزئیات را در اینترنت جستجو کنید،
220
00:09:06,680 –> 00:09:10,080
کاری که من انجام می دهم این است که یک شی dlm در اینجا
221
00:09:10,080 –> 00:09:12,390
با استفاده از یک کتابخانه قفل خواندن پایتون
222
00:09:12,390 –> 00:09:15,360
توسط سالواتوری در صفحه قفل قرمز
223
00:09:15,360 –> 00:09:18,600
در وبسایت Rytas IL توصیه شده است. من یک
224
00:09:18,600 –> 00:09:20,550
اتصال اعتباری به سرور آماده
225
00:09:20,550 –> 00:09:23,010
مشخص کننده پورت در یک پایگاه داده دریافت میکنم، متوجه خواهید
226
00:09:23,010 –> 00:09:24,360
شد که حتی اگر یک
227
00:09:24,360 –> 00:09:26,670
اتصال مشخص کردهام، این متغیر یک
228
00:09:26,670 –> 00:09:28,950
آرایه است تا بتوانم چندین سرویس آماده را مشخص کردهاند
229
00:09:28,950 –> 00:09:31,110
، مردانی برای
230
00:09:31,110 –> 00:09:33,900
حل مشکل شماره 3 وجود دارند، جایی که ما نمیخواهیم
231
00:09:33,900 –> 00:09:36,420
مکانیسم قفل خواندن ما
232
00:09:36,420 –> 00:09:37,830
در نقطه شکست به یک نقطه تبدیل شود.
233
00:09:37,830 –> 00:09:38,280
234
00:09:38,280 –> 00:09:42,210
و
235
00:09:42,210 –> 00:09:44,130
اگر به هر دلیلی
236
00:09:44,130 –> 00:09:46,320
فرآیند من نتواند قفل را در اولین
237
00:09:46,320 –> 00:09:48,570
بار دریافت کند، یک تاخیر به این صورت است، پس از سه بار دوباره امتحان میکند
238
00:09:48,570 –> 00:09:50,910
و سپس من این روش به نام
239
00:09:50,910 –> 00:09:53,540
دادههای وارداتی را دارم که یک منطق زمانبندی است،
240
00:09:53,540 –> 00:09:56,520
سعی میکنم قفلی را در اینجا مشخص کنم.
241
00:09:56,520 –> 00:09:59,700
کلید و TTL در میلی ثانیه پس از آن
242
00:09:59,700 –> 00:10:01,770
اگر من با موفقیت در
243
00:10:01,770 –> 00:10:03,600
به دست آوردن قفل موفق باشم،
244
00:10:03,600 –> 00:10:05,790
کار را اجرا می کنم و تمام کاری که من در اینجا انجام می دهم این است
245
00:10:05,790 –> 00:10:08,910
که کار را در صف قرار دهم، این روش نشانه
246
00:10:08,910 –> 00:10:10,860
از کتابخانه نشانه ما که قبلاً
247
00:10:10,860 –> 00:10:12,810
ذکر کردم می آید و این کار را فشار می دهد.
248
00:10:12,810 –> 00:10:14,880
دادهها را بهجای
249
00:10:14,880 –> 00:10:17,130
نوشتن در زمان واقعی در یک لیست Redis اضافه کردم و سپس من
250
00:10:17,130 –> 00:10:19,620
یک زمان خواب نقطهای اضافه کردم، دلیل اینکه این کار را انجام دادم این بود
251
00:10:19,620 –> 00:10:21,780
که میخواهم مطمئن شوم که
252
00:10:21,780 –> 00:10:23,970
زمان اجرای این تکه
253
00:10:23,970 –> 00:10:27,470
کد بیشتر از حداکثر تلاش مجدد است
254
00:10:27,470 –> 00:10:29,640
در غیر این صورت اتفاقی که خواهد افتاد این است که
255
00:10:29,640 –> 00:10:32,400
اولین زمانبندی یک قفل به دست میآورد این کار را
256
00:10:32,400 –> 00:10:34,920
بسیار سریع انجام میدهد، زیرا صف کشیدن یک
257
00:10:34,920 –> 00:10:36,660
کار در Redis کسری از ثانیه طول میکشد
258
00:10:36,660 –> 00:10:40,350
و سپس قفل را آزاد میکند،
259
00:10:40,350 –> 00:10:41,940
اما یک زمانبندی دوم وجود دارد که
260
00:10:41,940 –> 00:10:45,660
موازی را اجرا میکند و کاری که انجام می دهد این است که سعی می کنم
261
00:10:45,660 –> 00:10:48,360
قفلی را بدست بیاورم، شکست می خورد و
262
00:10:48,360 –> 00:10:51,510
دوباره تلاش می کند، اما این نقطه دو
263
00:10:51,510 –> 00:10:54,030
ثانیه بیش از زمان کافی برای انجام این
264
00:10:54,030 –> 00:10:56,640
عمل در صف کار است، بنابراین
265
00:10:56,640 –> 00:10:58,230
زمان بندی دوم فکر می کند که به سادگی
266
00:10:58,230 –> 00:11:00,450
مقداری دارد. نوعی زمانبندی شبکه
267
00:11:00,450 –> 00:11:02,190
، قفل سیمی را مشاهده کنید
268
00:11:02,190 –> 00:11:03,600
و با اجرای این کد
269
00:11:03,600 –> 00:11:05,850
کسری از ثانیه پس از اتمام اولین
270
00:11:05,850 –> 00:11:07,590
زمانبندی که من قبلاً آن را تمام کرده بودم، ادامه
271
00:11:07,590 –> 00:11:09,900
مییابد که این اصل را نقض میکند
272
00:11:09,900 –> 00:11:11,580
که فقط یک فرآیند میتواند در هر
273
00:11:11,580 —