بهترین روش اتصال بین لوکال و اینترنت بدون استفاده از وب سرویس ؟
با سلام خدمت مهندسین عزیز
من 2 تا برنامه جداگانه دارم هردو php و mysql استفاده میکنن یکی لوکال و یکی روی اینترنت هست میخاستم اطلاعات روی وب بصورت همزمان یا با فراخوانی از طرف لوکال به اون منتقل بشه.برای مثال شما برنامه ای دارید که نوبت حضوری و اینترنتی میده حالا میخاهیم نوبت های آنلاین و لوکال با هم هماهنگ باشن و تکراری نشن بهترین کار چیه یا چه روشی میتوان استفاده کرد؟لطفا وب سرویس یا انتقال برنامه لوکال به وب رو پیشنهاد ندین ممنون
چرا پیشنهاد ندیم ؟
امکان استفاده از برنامه های ویندوزی نیست ؟ چرا با خود اسکریپت از لوکال به mysql هاست وصل نمیشید ؟
چون اگر امکان اين کار بود خودم انجام ميدادم ولي اونجا اينترنت وصل هست.اين راه قبلا تست کردم بد نيست ولي به نظرم بهينه نيست اگر پيشنهاد خاص يا کدي در اين رابطه دارين خوشحال ميشم بذارين
چطور؟ چرا؟نوشته شده توسط imanitc
من قبلا يه صفحه ساخته بودم که يه کدي رو با گت به اون ميفرستادم اگر کد درست بود يه سري اطلاعات بصورت کد شده بر ميگردوند به سمت من حالا نميدونم اين کار درست بوده يا نه ؟راه ديگه اي يا استانداردي چيزي هست براي اين کار؟اين روش خودم و جايي نديدم
این که گفتی جواب من بود؟
خیلی کلی و مبهم هست؛ نمیشه چیزی گفت.من قبلا يه صفحه ساخته بودم که يه کدي رو با گت به اون ميفرستادم اگر کد درست بود يه سري اطلاعات بصورت کد شده بر ميگردوند به سمت من حالا نميدونم اين کار درست بوده يا نه ؟راه ديگه اي يا استانداردي چيزي هست براي اين کار؟اين روش خودم و جايي نديدم
بستگی داره دقیقا چه کدی چطوری چه روش کدی چه اطلاعاتی برای چه کاری از چه نظر...
آقا کد من و نظر من ول کن .شما اگر خودت کدي يا نظري داري اعلام کن استفاده کنيم
ارسال اطلاعات که امروزه به ده ها روش ممکنه. امکاناتش هم راحت و همه جاییه تقریبا.
تا جزییات دونسته نشه نمیشه گفت کدوم روش و نمیشه از جزییات صحبت کرد.
مسائل امنیتی و غیره هم که جداگانه هستن.
اما خب آدم بطور کلی امروزه روشی رو انتخاب میکنه که از نظر کدنویسی راحتتر و سریعتر باشه، مگر اینکه شرایط طوری باشه و در عمل مشکلات/محدودیت های فنی وجود داشته باشن. مثلا شما گفتی بنظرت بهینه نیست. واسه همین پرسیدم چرا! چون این بنظر نشانهء اینه که ممکنه کم و بیش دچار وسواس در بهینه سازی شده باشه (این یه بیماری نسبتا شایع بین برنامه نویسان است که قبلا راجع بهش زیاد بحث کردم). بنظر منظر نداره! یا هست یا نیست. در عمل باید وجود داشته باشه، نه بنظر! باید دلیل و سند معتبر داشته باشه حداقل اگر ذهنی هم هست.
در درجهء بعد آدم اگر به هر دلیلی استاندارد بودن و امکان تعامل با برنامه ها و سرویسهای دیگران براش مهم باشه، میره دنبال استاندارد بودن روش (مثلا وب سرویس یا روشهای استاندارد دیگر). وگرنه که خودش شده یه پروتکل و روشی اختراع میکنه!! کاری نداره که!!
البته بازم مسائل امنیتی نیاز به تخصص دارن. مثلا اطلاعات رو طوری بفرستی که دیگران نتونن دسترسی داشته باشن یا دستکاری کنن در مسیر.
حالا از این بیشتر چی میخوای الان؟ بیایم کد و برنامه هم بنویسیم بذاریم؟ اونم وقتی اطلاعات و شرایطش دقیقا معلوم نیست چطوریه؟
با تشکر از شما دوست عزيز من مشکلم همون که توي سوال اول تاپيک مطرح کردم نوبت دهي آنلاين و لوکالي همزمان، ذخيره سازي در هر دو ديتا بيس يعني لوکال و آنلاين حالا مشکل سينک کردن اين 2 تاس حالا چيکار کنم ؟
سینک کردن که میگید، با مشکلات همزمانی فرق داره بنظرم.
سینک کردن یعنی یکسان کردن دو منبع.
ولی سینک کردن ارتباطی به مشکلات همزمانی نداره و نمیتونه این مشکل رو حل کنه.
مثلا اگر یک صندلی در هر دو دیتابیس به افراد مختلفی اختصاص داده شده باشه، سینک کردن اینجا معنایی نمیده و قابل انجام نیست.
درمورد مشکل همزمانی هم خب چرا دو دیتابیس؟ نمیشه از یک دیتابیس مشترک استفاده کرد؟
نهایت باید یه ارتباطی بین هر دو برنامه (لوکال و آنلاین) برقرار بشه، حداقل در مواقعی که رکوردی میخواد درج بشه؛ حالا دیتابیس رو مشترک نکردید، ولی حداقل یک تبادل اطلاعات و چک بین دو سیستم باید صورت بگیره یا نه؟
مثلا سیستم آنلاین میخواد یک صندلی رو رزو کنه، باید اول با سیستم لوکال تماس بگیره ببینه این صندلی رزو شده یا نه، بعد رکورد رو درج کنه در دیتابیس خودش. تازه باید یک قفل هم بذارید روی سیستم لوکال که در همین زمان کوتاه، اون صندلی رو رزرو نکنه. سیستم لوکال هم باید برای رزور صندلی، با سیستم آنلاین تماس بگیره، اما اصولی و دقیق و بی نقص بخواد باشه فقط این کافی نیست. فرض کنید دو سیستم همزمان برای یک صندلی همدیگر رو کوئری میکنن، هر دو جواب میگیرن که صندلی رزور نشده، بعد هر دو اون صندلی رو اختصاص میدن! اینطوری مشکل پیش میاد؛ نه؟ پس نیاز به قفل و فراینده پیچیده تری هست.
فکر میکنم مشترک کردن دیتابیس احتمالا بتونه این پیچیدگی رو کاهش بده. یعنی جلوگیری از چنین وقایعی در یک دیتابیس مشترک فکر میکنم ساده تر باشه (نه اینکه هیچ توجه و تمهیدی نخواد).
سلام جناب eshpilen, نیستی آقا؟
یه چند وقت پیش یه همچین پروژه ای داشتم. بعد از کلی تحلیل و بررسی روش های به این نتیجه رسیدم که بهترین کار اینه که دیتابیس آنلاین, مشترک برای هر دو برنامه استفاده بشه. یعنی برنامه لوکال و آنلاین به این دیتابیس که روی هاست قرارداره متصل بشن.
وقتی از طریق سیستم لوکال بخوان از نرم افزار استفاده کنند باید به اینترنت وصل باشند که در این صورت و طبق گفته های شما مشکلی به وجود نمیامد و راحت از طریق لوکال یا خود سایت میشه اطلاعات یکسانی رو اضافه و ویرایش و ... کرد. ولی مشکل اینجا بود که طرف میخواست قادر باشه بدونه اینترنت هم از برنامه لوکال استفاده کنه.
خب اومدم یه کلیدی تو برنامه لوکال تعبیه کردم و یه دیتابیس جدا در لوکال ساختم که وقتی این کلید رو میزدی آخرین اطلاعات هاست آنلاین رو دریافت و دیتابیسشو آپدیت میکرد. در این صورت فقط میتونستی از برنامه و اطلاعات فعلیش استفاده کنی و قابلیت ویرایش, حذف و اضافه کردن اینا نداشت و جز اینهم راهی نداره.
البته فقط دیتابیش مشترک لزوما همهء مشکلات همزمانی رو حل نمیکنه.
این قضیهء دسترسی همزمان در خیلی از برنامه ها درنظر گرفته نشده.
یعنی حتی دو درخواستی که به یک سرور وارد میشن، و کوئری هایی که هرکدام اجرا میکنن، ترتیب اجرای اینها میتونه هرچیزی باشه، مثلا اول کوئری 1 از درخواست A اجرا بشه بعد کوئری 1 از درخواست B بعد کوئری 2 درخواست A و ... . اینطوری نیست که چون درخواست A قبل از درخواست B به سرور وارد یا حتی اول شروع به اجرا شده، ترتیب اجرای کدهای درخواست ها هم به همین شکل باشه. ترتیب اجرای کدها در سیستم عامل و برنامه های مربوطه تضمین نشده.
اینا میتونه موجب خطا در داده های ثبت شده بشه.
هرکجا که منبع مشترکی توسط چند فرایند مورد استفاده قرار میگیره این مسائل دسترسی همزمان میتونن بروز کنن.
یه مثال:
یه فیلد داریم که مقدار اعتبار مالی رو ذخیره میکنه.
فرضا مقدار اولیه 1000 تومن.
درخواست A میخواد این مقدار رو بخونه (و فرضا ممکنه میخواد یکسری عملیات محاسبهء مالیاتی چیزی هم روش انجام بده) و 500 تومن بهش اضافه کنه.
درخواست B هم میخواد 500 تومن دیگه بهش اضافه کنه.
درخواست A با اجرای یک کوئری مقدار 1000 رو از این فیلد میخونه، در این بین درخواست B هم 1000 رو میخونه، درخواست A مقدار 1500 رو در فیلد مینویسه، بعدش درخواست B هم میاد همین مقدار رو مینویسه!
اینجا مشاهده میکنیم که بجای 1000 تومن در مجموع، 500 تومن به اعتبار اضافه شده.
این یه نمونه خیلی ساده از مشکل دسترسی همزمان!
فکر نکنم نیازی به دریافت آخرین اطلاعات هاست آنلاین باشه!خب اومدم یه کلیدی تو برنامه لوکال تعبیه کردم و یه دیتابیس جدا در لوکال ساختم که وقتی این کلید رو میزدی آخرین اطلاعات هاست آنلاین رو دریافت و دیتابیسشو آپدیت میکرد. در این صورت فقط میتونستی از برنامه و اطلاعات فعلیش استفاده کنی و قابلیت ویرایش, حذف و اضافه کردن اینا نداشت و جز اینهم راهی نداره.
کافیه شما مواردی رو که زمان آفلاین ثبت میشن رو داخل یه جدول ثبت کنی بعد هر وقت که اینترنت فعال شد اون موارد رو به سایت اصلی میفرسته و در صورت دریافت پاسخ success اون رکورد رو حذف میکنه.
البته به نظرم بهتره واسه لوکال یه برنامه تحت دسکتاپ مستقل نوشت. اینطوری راحت تر میشه کا رو انجام داد.
اینطوری میتونی مستقیما به دیتابیس هاست اصلی وصل بشی و اطلعات رو درج کنی.(البته اینجا مسئله امنیت پیش میاد چون اگه راهکاری انجام ندی پسوردت 3 سوت لو رفته
بله موافقم.
البته رو این هم فکر کردم. راه و روشهای مختلفی به ذهنم رسید ولی نهایتا هیچکدوم رو اجرا نکردم.
مثلا میخواستم درخواستهای که از برنامه لوکال ارسال میشه رو فقط در ثانیه های فرد اجراش کنم و درخواستهای سایت رو فقط در ثانیه های زوج. اینطوری احتمال درصد خطاش 0 میشه. نظرتون چیه؟
یا مثلا درخواستهای که ارسال میشن یه آی دی یونیک بهشون بدیم و بریزیم تو یه لیست انتظار و 100 هزارم ثانیه یه درخواست رو اجرا کرد. این روش کمی پیچیدگی بالای و احتمال اشتباه داره, ولی بلاخره روشه دیگه
آخرین ویرایش به وسیله colors : دوشنبه 13 آبان 1392 در 11:35 صبح
فکر کنم اشتباه متوجه شدین.
برنامه آفلاین عملا نمیتونه رکوردی رو حذف اضاف یا ... کنه مگر اینکه سیستم پایه برنامه آفلاین به اینترنت وصل بوده باشه که بتونه با دیتابیس آنلاین ارتباط برقرار کنه.
اگر بخوای خود برنامه آفلاین زمان وصل نبودن به اینترنت قادر به ویرایش اطلاعات باشه و هر وقت وصل شدی آپدیت کنه, این مشکل داره. چند پست بالاتر دوستان گفتن که مثلا همون بحث رزرو صندلی تو اینجور مواقع پر از مشکل میشه.
مثلا یه اتوبوس VIP 30 نفره واسه 185 نفر رزرو میشه
شما به خیال خودت در زمان خاصی چیزی رو اجرا میکنی، ولی زمانبندی دقیق هیچوقت دست شما نیست و به هزارتا پارامتر در محیط سخت افزاری و نرم افزار و ارتباطات سرور و رایانه بستگی داره.
یعنی چی در ثانیه های فرد و زوج؟
مثلا تایم رو میگیری توی حلقهء while هروقت زوج بود دستور رو اجرا میکنی؟
اصلا شما نمیتونی به هیچ صورتی مطمئن باشی که زمانی که دستور رو به خیال خودت اجرا کردی اجرای واقعی اون چه زمانی در کامپیوتر شروع میشه و با چه سرعتی اجرا میشه و کی تموم میشه.
اینا هیچکدام تضمین و قاعدهء قابل اتکایی ندارن. سیستم بر اساس الگوریتم و اولویت و پارامترهای زیادی این کارها رو انجام میده.
ضمنا مگه فکر کردی اجرای هر دستور و درخواست و عملیاتی بیشتر از یک ثانیه طول نمیکشه؟
اینم تضمین نداره.
شاید برنامهء شما خیلی سبک باشه اما سرور به علت خاصی خیلی کندتر میشه و اجراش خیلی بیشتر طول میکشه.
متوجه نشدم چی میگی. ولی فکر کنم اینم مثل قبلی روی فرضهای اشتباهی استواره.یا مثلا درخواستهای که ارسال میشن یه آی دی یونیک بهشون بدیم و بریزیم تو یه لیست انتظار و 100 هزارم ثانیه یه درخواست رو اجرا کرد. این روش کمی پیچیدگی بالای و احتمال اشتباه داره, ولی بلاخره روشه دیگه
بازم خشونت
به خاطر همین دلایل بود که اجراشون نکردم.
بهرحال واسه این دسترسی همزمان روشهای اصولی تر خودش هست.
مثلا قفل. مکانیزم های قفل رو واسه همین چیزا گذاشتن دیگه!
فکر کنم از ترنزکشن هم میشه استفاده کرد (چون خودم تاحالا استفاده نکردم زیاد مطمئن نیستم).
نخیر فکر نکنم اشتباه متوجه شده باشمفکر کنم اشتباه متوجه شدین.
برنامه آفلاین عملا نمیتونه رکوردی رو حذف اضاف یا ... کنه مگر اینکه سیستم پایه برنامه آفلاین به اینترنت وصل بوده باشه که بتونه با دیتابیس آنلاین ارتباط برقرار کنه.
اگر بخوای خود برنامه آفلاین زمان وصل نبودن به اینترنت قادر به ویرایش اطلاعات باشه و هر وقت وصل شدی آپدیت کنه, این مشکل داره. چند پست بالاتر دوستان گفتن که مثلا همون بحث رزرو صندلی تو اینجور مواقع پر از مشکل میشه.
مثلا یه اتوبوس VIP 30 نفره واسه 185 نفر رزرو میشه
چیزی که گفتم اصلا به صندلی و اوتوبوس ربط نداره! لطفا با دقت بخونین.
بله سیستم آفلاین نمیتونه رکوردی رو حذف کنه منم اون حرفها رو بر پایه پست قبلی شما نوشتم.
اگه بخوام کامل بگم...
فرض کنیم کاربر به اینترنت وصل نیست و میخواد یه رکورد ثبت کنه، تو دیتابیسی که تو لوکال درست کردیم اون رکورد رو ثبت میکنیم پس قطعا کاربر نمیتونه رکورد هایی که تو دیتابیس اصلی هستن رو ویرایش یا حذف کنه چون لیست رکوردها رو نداریم و فقط یه جدول موقت داریم.
بعد تو یه بازه زمانی مشخص با تایمر چک میکنیم که سیستم به اینترنت وصله یا نه؟(یا هوک
حالا به نظرتون اشتباه فهمیدم؟
البته اینا رو بر پایه برنامه تحت دسکتاپ گفتم....تایمر و اینجور چیزا
بازم نقهمیدم.نخیر فکر نکنم اشتباه متوجه شده باشم
چیزی که گفتم اصلا به صندلی و اوتوبوس ربط نداره! لطفا با دقت بخونین.
بله سیستم آفلاین نمیتونه رکوردی رو حذف کنه منم اون حرفها رو بر پایه پست قبلی شما نوشتم.
اگه بخوام کامل بگم...
حالا به نظرتون اشتباه فهمیدم؟
البته اینا رو بر پایه برنامه تحت دسکتاپ گفتم....تایمر و اینجور چیزا
بله مشکلی نیستفرض کنیم کاربر به اینترنت وصل نیست و میخواد یه رکورد ثبت کنه
بله درستهتو دیتابیسی که تو لوکال درست کردیم اون رکورد رو ثبت میکنیم
هیچ شکی نیستپس قطعا کاربر نمیتونه رکورد هایی که تو دیتابیس اصلی هستن رو ویرایش یا حذف کنه چون لیست رکوردها رو نداریم و فقط یه جدول موقت داریم.
بسیار عالیبعد تو یه بازه زمانی مشخص با تایمر چک میکنیم که سیستم به اینترنت وصله یا نه؟ (یا هوک
اینجارو خراب کردی.اگه وصل بود شروع میکنه اطلعات رو میفرسته به هاست و اونا رو ذخیره میکنه بعد از جدول موقت حذفشون میکنه.
خب در این صورت اگر سیستم آفلاین در طول روز بلیط های شماره 1 تا 10 رو رزرو کنه و کاربر سیستمش رو ساعت 20 به اینترنت وصل کنه که اطلاعات رو بفرسته به هاست, و همه بیلط های اتوبوس(حتی بلیط های 1 تا 10) تا قبل از ساعت 19 توسط سایت رزرو شده باشه, میخوای چیکار کنی؟
وقتی که کاربر ساعت 20 وصل شد و اطلاعات به هاست رفت میبینه که اون رکوردها قبلا تو دینابیس درج شدن و دعوا شروع میشه.
خب بدیهیه که قبل از ثبت رکورد باید یه بررسی هایی انجام بشه!خب در این صورت اگر سیستم آفلاین در طول روز بلیط های شماره 1 تا 10 رو رزرو کنه و کاربر سیستمش رو ساعت 20 به اینترنت وصل کنه که اطلاعات رو بفرسته به هاست, و همه بیلط های اتوبوس(حتی بلیط های 1 تا 10) تا قبل از ساعت 19 توسط سایت رزرو شده باشه, میخوای چیکار کنی؟
وقتی که کاربر ساعت 20 وصل شد و اطلاعات به هاست رفت میبینه که اون رکوردها قبلا تو دینابیس درج شدن و دعوا شروع میشه.
اونم بستگی داره به سیستم شما. خیلی بدیهیه!
مثلا چه بررسی های ؟
آقا سامان گیر دادیا
خب مثلا واسه رزرو بلیط وقتی که اطلاعات به سرور ارسال شد بررسی بشه آیا این صندلی رزو شده یا نه؟ آیا زمان حرکت اتوبوس گذشته یا نه؟
اگه مشکلی بود به کاربر خطا بده اگه نبود هم که هیچی!
من با سیستم رزرو بلیط آشنا نیستم وگرنه دقیق تر جواب میدادم. اینا به جزئیات پروژه مربوط میشه نه روش انجام کار. ما روی روشها بحث میکنیم الان.
آقا سامان گیر دادیا
خب مثلا واسه رزرو بلیط وقتی که اطلاعات به سرور ارسال شد بررسی بشه آیا این صندلی رزو شده یا نه؟ آیا زمان حرکت اتوبوس گذشته یا نه؟
اگه مشکلی بود به کاربر خطا بده اگه نبود هم که هیچی!
من با سیستم رزرو بلیط آشنا نیستم وگرنه دقیق تر جواب میدادم. اینا به جزئیات پروژه مربوط میشه نه روش انجام کار. ما روی روشها بحث میکنیم الان.
خب دقیق مشکل همینجاست که اگه سیستم بخواد به هاست کوئری بفرسته که ببینه این صندلی رزرو شده یا خیر, باید به اینترنت متصل باشه, درسته؟ پس اگه قرار به اینترنت وصل بشی که اینارو چک کنی همون اطلاعات رو به دیتابیس آنلاین(هاست) میفرستی راحت. این همه پیچیدگی و دردسرهم نداره. درسته؟
آقا! برنامه چک میکنه که آیا سیستم به اینترنت وصله یا نه؟ بعد شروع میکنه به سینک کردن و بعد موقع سینک کردن بررسی میکنه که آیا صندلی رزو شده یا نه؟ بعد اگه ثبت شده باشه به کاربر خطا میده که این صندلی که شما موقع افلاین بودن ثبت کردین قبلا ثبت شده!
هم بله هم خیر. شما گفتین سیستم مثلا ساعت 8 به اینترنت وصل میشه برنامه هم به طور خودکار اون زمان عملیات رو شروع میکنه. تو پست 13 و 19 به این نکته اشاره کردم
خب دقیق مشکل همینجاست که اگه سیستم بخواد به هاست کوئری بفرسته که ببینه این صندلی رزرو شده یا خیر, باید به اینترنت متصل باشه, درسته؟
اصلا به جای این همه بحث کردن یه اشتراک adsl براش بگیر تا همون راحت بشیم!
بهتره دیگه بحث رو کشش ندیم دیگه. من توضیحاتی که تو نظرم بود رو دادم
باشه
آقا! برنامه چک میکنه که آیا سیستم به اینترنت وصله یا نه؟ بعد شروع میکنه به سینک کردن و بعد موقع سینک کردن بررسی میکنه که آیا صندلی رزو شده یا نه؟ بعد اگه ثبت شده باشه به کاربر خطا میده که این صندلی که شما موقع افلاین بودن ثبت کردین قبلا ثبت شده!
هم بله هم خیر. شما گفتین سیستم مثلا ساعت 8 به اینترنت وصل میشه برنامه هم به طور خودکار اون زمان عملیات رو شروع میکنه. تو پست 13 و 19 به این نکته اشاره کردم
اصلا به جای این همه بحث کردن یه اشتراک adsl براش بگیر تا همون راحت بشیم!
بهتره دیگه بحث رو کشش ندیم دیگه. من توضیحاتی که تو نظرم بود رو دادم
احساس میکنم استارتر تاپیک به شدت سردرگم شدند .استارتر محترم سعی کنید اول سناریو رو کامل کنید و سپس به دنبال کد و امنیت و با قیه ماجرا باشید .با سلام خدمت مهندسین عزیز
من 2 تا برنامه جداگانه دارم هردو php و mysql استفاده میکنن یکی لوکال و یکی روی اینترنت هست میخاستم اطلاعات روی وب بصورت همزمان یا با فراخوانی از طرف لوکال به اون منتقل بشه.برای مثال شما برنامه ای دارید که نوبت حضوری و اینترنتی میده حالا میخاهیم نوبت های آنلاین و لوکال با هم هماهنگ باشن و تکراری نشن بهترین کار چیه یا چه روشی میتوان استفاده کرد؟لطفا وب سرویس یا انتقال برنامه لوکال به وب رو پیشنهاد ندین ممنون
سناریو ی بنده :
دو بانک اطلاعاتی دارید یکی در هاست یکی در لوکال . بانک اطلاعاتی در لوکال فقط برای دخیره است و نه برای پردازش . بانک اطلاعاتی در هاست برای پردازش و دخیره است . ساختار هر بانک کاملا شبیه به هم هستند با ایت تفاوت که بانک موجود در هاست دارای فیلد اضافه ایی به نام check دارد .هر رکوئستی از هر جایی به بانک اطلاعاتی هاست امد برای رزرور مقدار چک را به 1 اپدیت میکند.اگر رکوئست از هاست آمد مقدار check را 1 میکند وپردازش ها را جهت رزرور انجام می دهد و اول داده ها رابه بانک موجود در لوکال (با static ip) انتقال می دهد و سپس داده ها را در بانک هاست اینسرت میکند.
وقتی درخواست رزرور از لوکال آمد (به هاست) اول مقدار چک را پردازش و ست میکند و سپس بعد از پردازش رزرواسیون اول داده ها را در هاسیت اینسرت و سپس در لوکال اینسرت میکنند .
با این روزش وقتی از هر طرفی رکوئستی آمد بانک فقط برای همان سمت قفل می شود و مشکل isolate را حل میکند.
پیشنهاد بنده : با دوتا یانک اطلاعاتی فکر نکنم به مشکل برسید . بانک اطلاعاتی در هاست یا لوکال میتواند به راحتی جا رزرو کند . فیلدی در بانک اطلاعاتی قرار بدید به نام Check. هنگام رزرو در لوکال یا هاست چک کنید اگر مقدار آن 1 بود یعنی از سمت لوکال یا هاست در حال چک کردن رزروها و انجام رزرو است . هنگام رزرو کردن در لوکال یا هاست یک کوئری بزنید اگر مقدار check برابر یا 0 بود آن را 1 کنید که در هیچ سمتی رزرو انجام نشود . بعد از پردازش هاتون میتونید رزرو رو انجام بدید و مقدار check را به 0 تغییر دهید و یعد از ثبت در هاست مقادیر رو لوکال اینسرت کنید.
در صورت داشتن شرایط اینترنتی normal فکر میکنم سناریوی بدی نباشه
راه حل خوبیه ولی در هرصورت محدودیت بیشتر ما در پستهای بالا, ارسال دو درخواست به صورت همزمان بود.
بله مشکل Isolation , ولی برای این مشکل بنده فیلد check را در بانک هاست پیشنهاد دادم. یعنی زمانی که رکوئستی از هر طرفی آمد این فیلد به مقدار 1 اپدیت میشود که از هیچ سمتی کسی بانک را در دست نگیرد . و مشکل همزمانی هم به مراتب به وجود نمی آید . بعد از پردازش ها و اینسرت در آخر این مقدار check به 0 تغییر میکند تا بانک را برای رکوئست های بعدی اماده کند . انشالله متوجه شماتیک کلی کار شده باشید
آقای علی رضا خب اگر دو درخواست همزمان از سایت و لوکال بیاد و هر دو مقدار فیلد check رو 0 کنن, پس هر دو میتونن عملیاتشونو انجام بدن درسته؟
نقل قول پست بالای از آقای eshpilen رو ببینید.
بنظرت ممکن نیست دو درخواست بصورت همزمان مقدار این فیلد رو بخونن و ببینن مقدارش صفر است و بعد هر دو کوئری بدن برای 1 شدنش؟
اینطوری بازم هر دو درخواست همزمان اجرا میشن.
این مشکل خیلی وقت پیش در سیستم های بانک اطلاعاتی رابطه ایی حل شده است .تمامیه درخواست ها در یک صف قرار میگیرند و تک تک اجرا میشوند . فرض کنید برنامه ایی نوشتید که در شبکه باید داده ها را دست کاری و مدیریت کند . در این صورت چه باید کرد ؟ تمامیه درخواست ها بصورت صف تک تک اجرا میشوند که مشکل به وجود نیاید .
بدانید که:
--
اگر از انجین myisam استفاده میکنید از تکنیک تیبل لاک استفاده میکند یعنی موقعه ی دست کاری کل تیبل لاک میشود . اگر از inodb استفاده میکنید سطر مورد نظر لاک میشود(row lock).به همین خاطر است که inodb میتواند از ترنزکشن پیشتیبانی کند
--
دیدن این لینک هم خالی از لطف نیست
http://dev.mysql.com/doc/refman/5.0/en/lock-tables.html
فکر میکنم اشتباه میکنی و چیزی رو با مسئلهء دیگری اشتباه گرفتی.این مشکل خیلی وقت پیش در سیستم های بانک اطلاعاتی رابطه ایی حل شده است .تمامیه درخواست ها در یک صف قرار میگیرند و تک تک اجرا میشوند.
تمام کوئری های صادر شده از یک درخواست/کانکشن بنظر بنده هم در صف قرار میگیرن بقول شما.
ولی مسئلهء چند درخواست جداگانه، چند پراسس جداگانه، چند درخواست جداگانه است.
اصولا از نظر پرفورمنس هم بخوای درنظر بگیری این معنا نمیده. چون اگر DBMS بخواد در هر زمان فقط یک کوئری رو اجرا کنه (ولو روی یک جدول یا رکورد خاص)، پرفورمنس نمیتونه برای مقیاس های بزرگ و کوئری های سنگین کافی باشه. مثلا هزارتا کوئری read تقریبا همزمان میرسن برای یک جدولی یا رکوردی، اونوقت کوئری ای که آخر از همه وارد شده باید صبر کنه تا تمام کوئری های قبلی به ترتیب اجرا و تموم بشن؟ اگر کوئری ها نسبتا سنگین باشن اونوقت که زمان بیشتر هم میشه. اگر یک کوئری سنگین باشه یا بعلت کمبود موقتی منابع یا شرایط دیگری (مثلا انتظار برای I/O یا عملیاتی که به یک منبع خارجی وابسته است) دچار تاخیر بشه، کوئری های دیگر هم که اون شرایط رو ندارن باید منتظر بمونن؟
فکر نمیکنم اینطور باشه.
بعد لازم باشه میشه با نمونه کد هم تست کرد، که من از حالا شک چندانی ندارم که خلاف حرف شما رو نشان خواهد داد.
اصولا عملیات خواندن بطور معمول هیچ محدودیت و قفلی ندارن. یعنی همزمان هر تعدادی که سیستم جواب بده میتونن یک منبعی رو بخونن.
این تنها عملیات write هست که بطور موقت درخواستهای دیگر رو بلاک میکنه، چون اگر اینطور نباشه ممکنه اطلاعات ناقص آپدیت شده ای خونده بشن.
بخاطر همینه که به قفلی که موقع read ایجاد میشه shared lock گفته میشه، چون تمام درخواستهای خواندن میتونن این قفل رو بصورت همزمان در اختیار بگیرن (و فقط درخواستهای write باید صبر کنن تا تمام قفل های read آزاد بشن).
و به قفلی که موقع write ایجاد میشه exclusive lock گفته میشه چون در موقع نوشته شدن اطلاعات در رکورد/جدول هیچ کوئری دیگری نمیتونه به اطلاعات دسترسی پیدا کنه.
شما فکر میکنید مکانیزمهای مخصوص قفل کردن توسط برنامه نویس (مثل این یا همونی که خودت آوردی) و ترنزکشن و اینها برای چی بوجود آمدن؟فرض کنید برنامه ایی نوشتید که در شبکه باید داده ها را دست کاری و مدیریت کند . در این صورت چه باید کرد ؟ تمامیه درخواست ها بصورت صف تک تک اجرا میشوند که مشکل به وجود نیاید .
قفل که کاربرد اصلیش همینه. ترنزکشن هم یکی از کاربردهاش همینه بنظرم!
اینها رو برنامه نویس میتونه و باید استفاده کنه؛ دیتابیس خودش بصورت خودکار تشخیص و انجام نمیده.
با کد هم میشه براحتی تست کرد که کوئری های دو درخواست جداگانه میتونن با هر ترتیبی اجرا بشن.
خواستی بگو نمونه برنامهء تستش رو برات بذارم.
با سلام خدمت دوستان...
به نظر من ارسال داده ها در يك زمان به سرور كه اين وسط واسه كوئري ها پيش مياد و دوستان ميگن كه شايد هر دو در يك زمان دقيقا پيش بياد اصلا منطقي نيست الآن اينجا مثلا روي لوكال و آنلاين بحث شده حالا بيايم تراكنشهايي كه از سمت لوكال مياد رو هم فرض كنيم يه تراكنش از سمت آنلاينه كه اين هم منطقيه و هيچ فرقي به حال بانكمون نميكنه (البته با اين فرض كه يه بانك داريم و اون هم روي سروره) چون قراره مجموعه اي از تراكنشها بيان و انجام بشن.
خب پس ميشه گفت اگر لوكال رو هم در نظر نگيريم با اين تفاصيل كه هست بايد روي درخواستهايي هم كه در سمت آنلاين داريم مشكل داشته باشيم ديگه مثلا همين مثال جناب eshpilen مگه نميشه كه رو دوتا درخواست از سمت كاربران آنلاين پيش بياد؟
مگه ميشه كه نشه، ميشه ولي چرا اينجا هيچ مشكلي نداريم و هر كسي در هر زماني هر تراكنشي ايجاد ميكنه هيچ مشكلي پيش نمياد؟
از زماني كه يادمه دبيرستان بوديم اين طور مثائل تو كتابهاي ما بود و حل شده هم بود و به ما ياد ميدادنشون (كه هيچ وقتم چيزي ازشون ياد نگرفتم به شخصه ولي حل شده بود
حالا فكرشم نميشه كرد كه رو بانكهاي اطلاعاتي كه مهمترين نمونه بارز همين مثئله هست پياده سازي نشده باشه.
در كل ميخوام اينو بگم كه هيچ وقت نميشه 2 تا كوئري مربوط به يه كار كه حتي 1% احتمالش بره تو كار هم اختلال ايجاد ميكنن در يك زمان اجرا نميشه و 100% خود پيكر بندي اين سيستم ها طوريه كه صف انتظار انجام تراكنش دارن دقيقا براي جلوگيري از همين برخورد 2 كوئري مثل هم با هم.
----
حالا اگر اين مورد قبول واقع بشه كه صف انتظار داريم و تمام تراكنش ها همزمان اجرا نميشن (كه بازم شايد من اشتباه ميكنم تو اين قضيه) قسمت دوم هم يعني تراكنشهاي لوكال هاست در صورتي كه حتي دو تا بانك باشه هم قابل حله كه برخورد نداشته باشن.
این صف انتظاری که چند پست بالاتر و اینجا بهش اشاره شد رو, میخواستم خودم پیاده سازی کنم ولی ...
اینجا متوجه نشدم چی گفتی, چطوری قابله حله؟
برای اینکه کوئری های چند درخواست با هم تداخل کنن نیازی نیست که دقیقا همزمان باشن.
من اکثرا میگم همزمان یا تقریبا همزمان، که افراد راحتتر درک کنن، ولی درواقع بحث زمانهای کوچک هست که در شرایط خاص میتونه تا چندین ثانیه هم برسه.
هیچ لزومی نیست که دقیقا همزمان باشن.
منکه نفهمیدم چی گفتی.اصلا منطقي نيست الآن اينجا مثلا روي لوكال و آنلاين بحث شده حالا بيايم تراكنشهايي كه از سمت لوكال مياد رو هم فرض كنيم يه تراكنش از سمت آنلاينه كه اين هم منطقيه و هيچ فرقي به حال بانكمون نميكنه (البته با اين فرض كه يه بانك داريم و اون هم روي سروره) چون قراره مجموعه اي از تراكنشها بيان و انجام بشن.
چرا میشه.خب پس ميشه گفت اگر لوكال رو هم در نظر نگيريم با اين تفاصيل كه هست بايد روي درخواستهايي هم كه در سمت آنلاين داريم مشكل داشته باشيم ديگه مثلا همين مثال جناب eshpilen مگه نميشه كه رو دوتا درخواست از سمت كاربران آنلاين پيش بياد؟
خب بستگی داره به برنامه، میزان ترافیک، نوع عملیات کاربران،و شانس و غیره.مگه ميشه كه نشه، ميشه ولي چرا اينجا هيچ مشكلي نداريم و هر كسي در هر زماني هر تراكنشي ايجاد ميكنه هيچ مشكلي پيش نمياد؟
مشکلات همزمانی چیزی نیست که هرجایی پیش بیاد یا هر زمانی پیش بیاد.
یه مواقع خاصی که همهء شرایط تصادفا (یا عمدا!) فراهم بشه، اونوقت تداخل پیش میاد.
از بین این تداخل هایی هم که پیش میاد، بعلت آمار پایین اونا، و اینکه در خیلی کاربردها مشکل و خسارت مهمی ایجاد نمیکنن، افراد کمی ممکنه متوجه تعداد کمی از اونا بشن. تازه افرادی که دقت و حوصلهء کافی داشته باشن و علت مسئله رو دنبال و پیدا کنن (که نیاز به دانش و بینش و مهارت کافی داره). اکثر افراد ممکنه فکر کنن اینکه مثلا یه روز یه داده ای خراب شد یه اتفاق دیگه ای بوده، یجورایی شانسی بوده، تقصیر چیز دیگه ای بوده، یا بهرحال حوصله ندارن یا نمیتونن و بیخیالش میشن.
بهرحال هر برنامه و عملیاتی و هر تراکنشی اونقدری مهم نیست که این مسئله توش مطرح باشه و به چشم بیاد و جدی گرفته بشه.
ولی مثلا در تراکنشهای مالی این مهم میشه.
بخاطر همین اگر از کسانی که در صنعت بانکداری و تجارت الکترونیک برنامه نویسی میکنن و تجربش رو دارن بپرسید، احتمالا خیلی بیشتر با این مسئله و راهکارهاش آشنا هستن.
بنده هم تجربهء عملی چندانی ندارم اما مثلا یک بار که برنامهء خودم رو با یک اسکنر امنیتی اسکن میکردم اینطور تداخل ها رو مشاهده کردم و پیگیر شدم و علتش رو حدس زدم. کس دیگری بود مسلم بدونید یا اصلا متوجه نمیشد یا پیگیری نمیکرد یا اصلا هرچی فکر میکرد بازم نمیتونست بفهمه. نمیخوام از خودم تعریف کنم، ولی اینطور باریک بینی ها و کشف باگهای ظریف کار هرکسی نیست. بلکه کار کسانی هست که 100 بار یه چیزی رو تست میکنه، یه بار میبینه یه کاراکتر نقطه یجا اضافه شده، یا یک چیزی چند پیکسل جاش تغییر کرد، یه چیزی درست کار نکرد، بیخیال نمیشه، نمیگه شانسی بود، بلکه میره ته و توش رو دربیاره که اون نقطه هه یا اون 2 پیکسل فضای اضافی از کجا اومد فلان چیز چرا اجرا نشد چی شد چطور شد منشاء چی بود! من همچین آدمی بودم همیشه؛ کوچکترین چیزی حتی یک بار تصادفا میدیدم، میرفتم دنبالش حالا یا ذهنی یا اگر میشد تست هم میکردم تا دست آخر بفهمم علتش چی بوده.
مثل اینکه که بگی چرا جلوگیری از SQL Injection در بانکهای اطلاعاتی پیاده سازی نشده.حالا فكرشم نميشه كرد كه رو بانكهاي اطلاعاتي كه مهمترين نمونه بارز همين مثئله هست پياده سازي نشده باشه.
نه عزیزم اینطور نیست که خود برنامه بتونه همهء این موارد رو بطور خودکار شناسایی و حل کنه.
بلکه خیلی جاها نیاز به تشخیص برنامه نویسه. این وظیفهء برنامه نویسه و هیچ نرم افزاری نمیتونه تمام این موارد رو بطور خودکار پوشش بده. بنابراین امکانات لازم برای جلوگیری از این موارد رو در اختیار برنامه نویس قرار دادن. این برنامه نویسه که باید بفهمه کجا باید از چه امکاناتی چرا استفاده کنه.
همونطور که مثلا توابع اسکیپ رو گذاشتن برای جلوگیری از SQL Injection، و این شما هستید که باید جای استفاده از اونا رو بفهمید و استفاده کنید، توابع و امکانات مربوط به مدیریت دسترسی همزمان رو هم گذاشتن، که شما خودتون باید بفهمید و استفاده کنید.
این مواردی که مد نظر منه چیزی نیست که تشخیص و حلش در سطح بانک اطلاعاتی باشه. در سطح کد و الگوریتمه و منطق برنامس، که فقط خود برنامه نویس میتونه ازش بطور کامل و دقیق مطلع باشه.
اون مواردی هم که در سطح بانک اطلاعاتی هستن، خب طبیعتا در همون سطح پیاده سازی شده و بصورت خودکار انجام میشن و ما بطور معمول باهاشون کاری نداریم.
شما اصلا قضیه رو متوجه نشدید.در كل ميخوام اينو بگم كه هيچ وقت نميشه 2 تا كوئري مربوط به يه كار كه حتي 1% احتمالش بره تو كار هم اختلال ايجاد ميكنن در يك زمان اجرا نميشه و 100% خود پيكر بندي اين سيستم ها طوريه كه صف انتظار انجام تراكنش دارن دقيقا براي جلوگيري از همين برخورد 2 كوئري مثل هم با هم.
مثالهایی که من زدم پس چی هستن؟
میخواید براتون نمونه کد و تست عملی هم بذارم؟
آخرین ویرایش به وسیله eshpilen : سه شنبه 14 آبان 1392 در 19:01 عصر
متاسفانه باید بگم سطح برنامه نویسان از نظر پایه خیلی پایینه.
هیچی نمیدونید از مسائل ظریف.
از همزمانی چیزی نمیدونید، از تداخل چیزی نمیدونید، از امنیت چیزی نمیدونید، از الگوریتم هم چیز زیادی نمیدونید.
ولی من اینقدر روی اینا تحقیق و تفکر داشتم که صرفا ذهنی میتونم خیلی از مسائل و باگها رو پیشبینی کنم. مواردی که بیشتر بقیهء افراد ممکنه هیچوقت متوجه وجود اونا هم نشن!
مثلا یادمه یک بار یکی اومده بود میپرسید که چرا سرویس شمارنده ای که توی سایتش استفاده میکنه آمارش ناگهان تغییر کرده و اشتباه شده.
بنده چیزی که بلافاصله به ذهنم رسید این بود که الگوریتم اون شمارنده، مسئلهء همزمانی و تداخل کوئری ها رو پیشبینی نکرده.
میبینید که اینطور باگها چیزهایی نیستن که براحتی و زیاد بروز کنن و از طرف دیگر موجب مشکل جدی ای بشن و افرادی روی کشف علتش جدیت به خرج بدن و بتونن نهایت علتش رو هم کشف کنن.
مثلا شاید اگر من به این مورد اشاره نمیکردم، کسی حدس درستی نمیزد و نهایت بیخیالش میشدن و قضیه فراموش میشد. غیر از اینه؟
اینطور مسائل چیزی نیست که انتظار داشته باشید براحتی بصورت تجربی آشکار و علتش کشف بشه.
ردی از خودش بجا نمیذاره. و براحتی نمیشه تستشون کرد.
در بیشتر موارد فقط گهگاهی و حتی بندرت یک چنین چیزهایی بصورت اسرارآمیزی رخ میده و ناپدید میشه.
گاهی میبینی حتی یک سال یک برنامه ای بدون هیچ مشکلی کار میکنه، بعد یک بار چنین باگی مشکل ایجاد میکنه که از زیر دست هم در نره. بستگی داره به شرایط. یک وقت میبینی شرایط طوری شد که بیشتر هم رخ داد و مشکل جدی ایجاد کرد. در مسائل حساس مثل امنیت و مسائل مالی هم که همون تعداد و احتمال اندک رو نمیشه نادیده گرفت.
آخرین ویرایش به وسیله eshpilen : سه شنبه 14 آبان 1392 در 19:04 عصر
اول بگم كه من اصلا در حد اين بحثا نيستم كه خيالتون راحت بشه و راحتتر جواب بدين بدون هيچ توهيني كه شايد پيش بياد تو تاپيكاي بعدي.
همون طور كه خودتون هم گفتيد بحث سر ميلي ثانيس و با توجه به سرعتي كه تو اين طور عمليات هست براي اين كه يه تراكنشي بخواد با يكي ديگه تداخل داشته باشه بايد تو هزارم ميلي ثانيه اين انجام بشه كه خيلي خيلي دور از انتظاره درسته و من نميدونم اگر پيش بياد چطور ميشه فهميد يا تشخيص داد...
خب ايني كه شما ميفرماييد درست ولي الآن واقعا اين مساله مبهمه چون تا حالا تو دنياي واقعي پيش نيومده يا اگرم پيش اومده ما ازش بي خبريم پس به اين نميشه استناد كرد كه شايد يه جايي يه خطايي باعثش اين تداخلها باشه و چون اون شخص دنبالش نرفته اين موضوع مبهم مونده تا يه مثال واقعي نباشه نميشه بهش استناد كرد...خب بستگی داره به برنامه، میزان ترافیک، نوع عملیات کاربران،و شانس و غیره.
مشکلات همزمانی چیزی نیست که هرجایی پیش بیاد یا هر زمانی پیش بیاد.
...........
تا دست آخر بفهمم علتش چی بوده.
والا من كه هرچي سرچ كردم هيچ چيزي در رابطه با اين مدريت زمان در پايگاه داده ها حتي يه سر نخ هم پيدا نكردم چه برسه به تابع و اين طور چيزا...مثل اینکه که بگی چرا جلوگیری از SQL Injection در بانکهای اطلاعاتی پیاده سازی نشده.
...
این شما هستید که باید جای استفاده از اونا رو بفهمید و استفاده کنید، توابع و امکانات مربوط به مدیریت دسترسی همزمان رو هم گذاشتن، که شما خودتون باید بفهمید و استفاده کنید.
اگر هست ما رو هم راهنمايي كنيد بريم ياد بگيريم.
و يه چيز ديگه به هيچ عنوان اصلا نميشه بحث Sql Injection رو با اين بحث يكي كرد چون اصلا يكي دوست داره تمام كاراكتر ها مجاز باشن و اگر اين از سمت خود بانك جلي گيري بشه يه نوع محدوديت محسوب ميشه و باعث شايد كم شدن طرفداراش كه اينو نميخواد قطعا و يه چيز ديگه هم اين كه مدريت زمان كار كاربر نيست كه بخواد خودش تو پروژه هاش انجام بده چون هيچ وقت اونا كاربرا شونو در اين سطحي كه شما تصور ميكنيد تصور نميكنن. ;)
يعني شما ميفرماييد كه يه بانك اطلاعاتي هيچ الگوريتمي پشتش نيست و حتي اگرم باشه اين مبحث هم كلا تو اونا نميگنجه!!این مواردی که مد نظر منه چیزی نیست که تشخیص و حلش در سطح بانک اطلاعاتی باشه. در سطح کد و الگوریتمه و منطق برنامس، که فقط خود برنامه نویس میتونه ازش بطور کامل و دقیق مطلع باشه.
اون مواردی هم که در سطح بانک اطلاعاتی هستن، خب طبیعتا در همون سطح پیاده سازی شده و بصورت خودکار انجام میشن و ما بطور معمول باهاشون کاری نداریم.
در اين باره يه جستو جويي زدم يه جا اينو نوشته بود (البته فكر ميكنم موصق نبود ولي تنها چيزي كه من پيدا كردم همين بود):
مديريت تداخل اطلاعات:
اين نوع مديريت مربوط به سرويسهاي بانكهاي اطلاعاتي در سطح شبكه مي باشد كه وظيفه كنترل دستيابي به فايلها را براي جلوگيري از تداخل دسترسي همزمان به فايلها را بر عهده دارد.
واقعا ميشه يه مساله به اين مهمي رو بيان واگذار كنن به كاربر بگن آقا شما هركار دوست داري بكن بلدي از خطاهاي احتمالي جلوگيري كن بلدم نيستي...!!!
و اگرم خطايي وجود داشته باشه كه اونا نتونسته باشن جلوشو بگيرن ديگه واي به حال باقيه البته نميخوام خودمونو دست كم بگيرم كه باز روشنفكران عزيز بريزن اينجا.
ولي يه كم فكر كنيم ميبينيم يه گروه معلوم نيست چند نفري از متخصصين نشستن اين كارو كردن حالا از اين چشم پوشي كردن ميشه!!!
خب حالا من يه مثال تو همون سبك خودتون ميزنم كه شما حدس بزنيد من فهميدم يا نه:شما اصلا قضیه رو متوجه نشدید.
مثالهایی که من زدم پس چی هستن؟
میخواید براتون نمونه کد و تست عملی هم بذارم؟
يه فيلد داريم كه مثلا مال ثبت نام يا يه مسابقس
حالا قراره 1000 نفر كه تعدادشون از قبل مشخصه تو يه ساعت جواب بدن به اون مسابقه يا ثبت نام كنن توش
حالا به نظر شما اون طور كه شما گفتيد بايد حداقل يه بار يه اختلال رخ بده و يه پاسخ ثبت نشه ديگه درسته
اصلا مسابقه نه چند نمونه مشابه هست كه تعداد تراكنشها مشخصه و بايد به همين ترتيبي كه هست اجرا بشن اينا به مشكل نخوردن!! حالا يكيشون مهم نبوده و مشكلشو نگفته كه 999 تا جواب داشتيم اوناي ديگه چي...
حالا تمام كساني كه اين برنامه ها رو نوشتن مدريت زمان انجام دادن؟ كه اين مشكل براشون پيش نيومده يا ميدونستن كه بايد انجام بدن يا نه اصلا پيش نيومده.
اگر مشكلي تو اين نوع پيش بياد كم كه نداريم از اين نمونه برنامه ها پس اگر خطايي بوجود اومده باشه بايد تو نت پر باشه از اين خطاها و مدريتشون ديگه.
تا جایی که میدونم، اگه به درستی از قفلها استفاده بشه، DBMS به اندازه کافی در زمینه مدیریت صف درخواستها خوب عمل میکنه. برای مثال، برنامه ای مثل نود رو درنظر بگیرین که با سیستم پیامک کار میکنه و به محض درخواست دادن، توی دیتابیس ثبت میشه. خوب در اینجا با اون حجم مشارکت مردم، خیلی پیش میاد که درخواستهایی همزمان برسن (البته باز هم نه کاملاً همزمان چون CPU توی فرکانسی داره کار میکنه که برای مثال، کوچکترین واحد زمانیش (Tick) چیزی بین 2 تا 3 میلیاردم ثانیه است. حالا چقدر احتمال داره توی این فاصله کوچک زمانی، دو درخواست دقیقاً همزمان برسن؟! اگه به فرض هم رسیدن، به محض اینکه یکیشون وارد شد، میتونه قفل بگذاره روی جدول و بقیه توی نوبت میمونن تا قفل آزاد بشه. بعلاوه توی لینوکس با نصب پکیج mysql-queues میشه این مدیریت رو بهتر کرد. بهتره درمورد Management of concurrent or simultaneous requests in MySQL یا بطور کلی هر DBMS دیگه، تحقیق مفصلی داشته باشین. کار با دیتابیس که فقط در حد یک کوئری ساده فرستادن نیست. اونهم توی پروژه هایی با حساسیت بالا. قفلها و سایر ابزارها هم برای تفریح گذاشته نشدن. یک مدیر دیتابیس قوی، از تمام این ابزارها برای جلوگیری از مشکلات احتمالی، استفاده بهینه میکنه.
قوانین ایجاد تاپیک در تالار
پاسخ با نقل قول
