Go Casts 🚀
سوال: توی معماری میکروسرویس باید حتما از یکی از این الگو ها استفاده و پیروی کرد؟ یکی از دوستان این سوال رو پرسیدند، در جواب باید بگم، بله استفاده از این الگوها عملا اجتناب ناپذیر هست، چرا؟ چون یکی از مهم ترین ویژگی های هر بیزینس availability هست، شما باید…
بسم الله الرحمن الرحیم
أَلسَّلٰامُ عَلَیکَ یٰا عَلی اِبنِ موسَی أَلرّضٰآ أَلمُرتَضٰی
Sharded Services
در الگوی Replicated همه Replica ها مثل هم هستن و همه شون این قابلیت رو دارن که به همه درخواست های ورودی پاسخ بدن ولی در الگوی sharded هر shard فقط قابلیت پاسخگویی به زیرمجموعه ای از درخواست هارو داره
یک load-balancer که root node نام داره مسئولیت توزیع کردن درخواست های ورودی به shard های متناسب با درخواست رو بر عهده داره
معمولا از Replicated services برای ساختن stateless services استفاده میشه ولی از Sharded services برای ساختن stateful services استفاده میشه.
#designing_distributed_systems_brendan_burns
@gocasts
أَلسَّلٰامُ عَلَیکَ یٰا عَلی اِبنِ موسَی أَلرّضٰآ أَلمُرتَضٰی
Sharded Services
در الگوی Replicated همه Replica ها مثل هم هستن و همه شون این قابلیت رو دارن که به همه درخواست های ورودی پاسخ بدن ولی در الگوی sharded هر shard فقط قابلیت پاسخگویی به زیرمجموعه ای از درخواست هارو داره
یک load-balancer که root node نام داره مسئولیت توزیع کردن درخواست های ورودی به shard های متناسب با درخواست رو بر عهده داره
معمولا از Replicated services برای ساختن stateless services استفاده میشه ولی از Sharded services برای ساختن stateful services استفاده میشه.
#designing_distributed_systems_brendan_burns
@gocasts
Go Casts 🚀
بسم الله الرحمن الرحیم أَلسَّلٰامُ عَلَیکَ یٰا عَلی اِبنِ موسَی أَلرّضٰآ أَلمُرتَضٰی Sharded Services در الگوی Replicated همه Replica ها مثل هم هستن و همه شون این قابلیت رو دارن که به همه درخواست های ورودی پاسخ بدن ولی در الگوی sharded هر shard فقط قابلیت…
Sharded Caching
به عنوان یه sharded caching system رو در نظر بگیرید، وقتی میخوایم چنین سیستمی رو طراحی کنیم، سوالات مختلفی به ذهن میاد، از جمله:
- Why You Might Need a Sharded Cache
تصور کنید کل دیتای قابل کش شدن ۲۰۰ گیگ باشه، و شما ۱۰ سرویس replica داشته باشید که هر کدوم قابلیت ذخیره سازی ۱۰ گیگ دیتارو داشته باشه، ازونجایی که در مدل replica احتمال مشابه بودن دیتا در replica های مختلف خیلی زیاده، عملا شما در لحظه ۵ درصد (۱۰ گیگ از ۲۰۰ گیگ) رو دارید کش میکنید و خب این خیلی عملکرد بدیه
اما حالا تصور کنید که همون ۱۰ تا نود جای این که replicated باشن بصورت sharded باشن و هر کدوم ۱۰ گیگ دیتای متفاوت از دیگری رو کش کنن، اینطوری تقریبا ۵۰ درصد دیتای شما (۱۰۰ گیگ از ۲۰۰ گیگ) رو دارید کش میکنید که خیلی خوبه
- The Role of the Cache in Your Architecture (System Performance)
سیستم کش در سه معیار performance, reliability و stability برنامه شما بسیار تاثیرگذاره
یک معیار مهم برای ارزیابی عملکرد سیستم کش میزان hit rate هست که بالاتر بهش اشاره کردیم. تصور کنید سیستم شما قابلیت پاسخگویی به ۱۰۰۰ درخواست در ثانیه رو داشته باشه و بیشتر از اون خطای ۵۰۰ به کاربر نشون داده بشه، با اضافه کردن یه سیستم کش با hit rate نزدیک به ۵۰ درصد، شما میتونید ۲۰۰۰ درخواست رو در ثانیه پاسخ بدید، پس میتونید ببینید سیستم کش چه نقشی میتونه در performance سیستم شما داشته باشه
اما فقط بحث تعداد درخواست های موفق و ناموفق نیست، یه نکته دیگه ای که خیلی در تجربه کاربری تاثیر داره بحث latency هست، عموما سیستم های کش بسیار سریع تر از برنامه شما به درخواست های ورودی پاسخ میدن که همین امر باعث میشه میانگین latency سیستم شما خیلی کمتر بشه
#designing_distributed_systems_brendan_burns
@gocasts
به عنوان یه sharded caching system رو در نظر بگیرید، وقتی میخوایم چنین سیستمی رو طراحی کنیم، سوالات مختلفی به ذهن میاد، از جمله:
- Why You Might Need a Sharded Cache
تصور کنید کل دیتای قابل کش شدن ۲۰۰ گیگ باشه، و شما ۱۰ سرویس replica داشته باشید که هر کدوم قابلیت ذخیره سازی ۱۰ گیگ دیتارو داشته باشه، ازونجایی که در مدل replica احتمال مشابه بودن دیتا در replica های مختلف خیلی زیاده، عملا شما در لحظه ۵ درصد (۱۰ گیگ از ۲۰۰ گیگ) رو دارید کش میکنید و خب این خیلی عملکرد بدیه
اما حالا تصور کنید که همون ۱۰ تا نود جای این که replicated باشن بصورت sharded باشن و هر کدوم ۱۰ گیگ دیتای متفاوت از دیگری رو کش کنن، اینطوری تقریبا ۵۰ درصد دیتای شما (۱۰۰ گیگ از ۲۰۰ گیگ) رو دارید کش میکنید که خیلی خوبه
- The Role of the Cache in Your Architecture (System Performance)
سیستم کش در سه معیار performance, reliability و stability برنامه شما بسیار تاثیرگذاره
یک معیار مهم برای ارزیابی عملکرد سیستم کش میزان hit rate هست که بالاتر بهش اشاره کردیم. تصور کنید سیستم شما قابلیت پاسخگویی به ۱۰۰۰ درخواست در ثانیه رو داشته باشه و بیشتر از اون خطای ۵۰۰ به کاربر نشون داده بشه، با اضافه کردن یه سیستم کش با hit rate نزدیک به ۵۰ درصد، شما میتونید ۲۰۰۰ درخواست رو در ثانیه پاسخ بدید، پس میتونید ببینید سیستم کش چه نقشی میتونه در performance سیستم شما داشته باشه
اما فقط بحث تعداد درخواست های موفق و ناموفق نیست، یه نکته دیگه ای که خیلی در تجربه کاربری تاثیر داره بحث latency هست، عموما سیستم های کش بسیار سریع تر از برنامه شما به درخواست های ورودی پاسخ میدن که همین امر باعث میشه میانگین latency سیستم شما خیلی کمتر بشه
#designing_distributed_systems_brendan_burns
@gocasts
Go Casts 🚀
Sharded Caching به عنوان یه sharded caching system رو در نظر بگیرید، وقتی میخوایم چنین سیستمی رو طراحی کنیم، سوالات مختلفی به ذهن میاد، از جمله: - Why You Might Need a Sharded Cache تصور کنید کل دیتای قابل کش شدن ۲۰۰ گیگ باشه، و شما ۱۰ سرویس replica داشته…
Replicated, Sharded Caches
گاهی اوقات سیستم کش به میزانی در عملکرد سیستم شما تاثیرگذاره که سیستم شما نمیتونه fail شدن یک shard رو تحمل کنه حتی برای مدت موقت، در این گونه مواقع میشه از ترکیب دو الگو استفاده کرد، یعنی یه سری shard وجود داشته باشه که دیتاهای متفاوتی از هم دارن، ولی هر shard خودش چند تا replica داشته باشه که این replica ها دیتای یکسانی دارن و در صورت fail شدن یکیشون node دیگه قادر به پاسخگویی هست
طبیعتا پیاده سازی این الگو پیچیدگی های خودشو داره، اما در کنار پیچیدگی ها، مزایای مهمی داره از جلمه resiliency در برابر failure هست.
نکته مهم دیگه اینه که شما میتونید shard های مختلف رو بر اساس لودی که دارن مستقل از یکدیگر scale بدید که بهش hot sharding میگن
#designing_distributed_systems_brendan_burns
@gocasts
گاهی اوقات سیستم کش به میزانی در عملکرد سیستم شما تاثیرگذاره که سیستم شما نمیتونه fail شدن یک shard رو تحمل کنه حتی برای مدت موقت، در این گونه مواقع میشه از ترکیب دو الگو استفاده کرد، یعنی یه سری shard وجود داشته باشه که دیتاهای متفاوتی از هم دارن، ولی هر shard خودش چند تا replica داشته باشه که این replica ها دیتای یکسانی دارن و در صورت fail شدن یکیشون node دیگه قادر به پاسخگویی هست
طبیعتا پیاده سازی این الگو پیچیدگی های خودشو داره، اما در کنار پیچیدگی ها، مزایای مهمی داره از جلمه resiliency در برابر failure هست.
نکته مهم دیگه اینه که شما میتونید shard های مختلف رو بر اساس لودی که دارن مستقل از یکدیگر scale بدید که بهش hot sharding میگن
#designing_distributed_systems_brendan_burns
@gocasts
Go Casts 🚀
Replicated, Sharded Caches گاهی اوقات سیستم کش به میزانی در عملکرد سیستم شما تاثیرگذاره که سیستم شما نمیتونه fail شدن یک shard رو تحمل کنه حتی برای مدت موقت، در این گونه مواقع میشه از ترکیب دو الگو استفاده کرد، یعنی یه سری shard وجود داشته باشه که دیتاهای…
An Examination of Sharding Functions
سوال مهمی که وجود داره اینه که اساسا بر طبق چه معیار و الگویی باید درخواست ها بین node های مختلف shard بشن؟
مسئولیت map کردن درخواست ورودی به یک shard خاص بر عهده sharding function هست.
معمولا sharding function خیلی شبیه به hashing function هست و مثلا bucket-based hashtable رو میشه عملا به عنوان sharding function استفاده کرد
معمولا برای sharding function از hashing function هایی استفاده میکنن که یه object رو هر چی که باشه به یه integer hash تبدیل میکنه، بعد از محاسبه باقیمانده اون integer بر تعداد shard ها، مشخص میشه که درخواست باید به کدوم shard ارسال بشه
این hash function باید دو تا خصوصیت داشته باشه:
Determinism
همیشه تابع برای یک ورودی خاص باید یک خروجی ثابت و معین رو برگردونه
Uniformity
توزیع خروجی تابع باید uniform باشه (اینطوری نباشه که روی یه سری shard ها لود وحشتناک بره و روی یه سری لودی نباشه)
ShardNO = hash(Req) % numberOfShards
#designing_distributed_systems_brendan_burns
@gocasts
سوال مهمی که وجود داره اینه که اساسا بر طبق چه معیار و الگویی باید درخواست ها بین node های مختلف shard بشن؟
مسئولیت map کردن درخواست ورودی به یک shard خاص بر عهده sharding function هست.
معمولا sharding function خیلی شبیه به hashing function هست و مثلا bucket-based hashtable رو میشه عملا به عنوان sharding function استفاده کرد
معمولا برای sharding function از hashing function هایی استفاده میکنن که یه object رو هر چی که باشه به یه integer hash تبدیل میکنه، بعد از محاسبه باقیمانده اون integer بر تعداد shard ها، مشخص میشه که درخواست باید به کدوم shard ارسال بشه
این hash function باید دو تا خصوصیت داشته باشه:
Determinism
همیشه تابع برای یک ورودی خاص باید یک خروجی ثابت و معین رو برگردونه
Uniformity
توزیع خروجی تابع باید uniform باشه (اینطوری نباشه که روی یه سری shard ها لود وحشتناک بره و روی یه سری لودی نباشه)
ShardNO = hash(Req) % numberOfShards
#designing_distributed_systems_brendan_burns
@gocasts
Go Casts 🚀
An Examination of Sharding Functions سوال مهمی که وجود داره اینه که اساسا بر طبق چه معیار و الگویی باید درخواست ها بین node های مختلف shard بشن؟ مسئولیت map کردن درخواست ورودی به یک shard خاص بر عهده sharding function هست. معمولا sharding function خیلی شبیه…
Selecting a Key
همونطور که در پست قبلی اشاره شد باید به تابع هش یک ورودی داده بشه، انتخاب اینکه ورودی تابع هش چی باشه خیلی مهمه.
فرض کنید بخوایم دو پارامتر ip و path (همون route درخواست) رو به عنوان ورودی تابع هش در نظر بگیریم:
shard(request.ip, request.path)
اتفاقی که میفته اینه که مثلا دو درخواست از یک کشور مثل فرانسه ممکنه به دو تا shard مختلف توزیع بشن که این اصلا خوب نیست، ما میخوایم دیتای موقعیت های جغرافیایی یکسان رو تو یه shard نگه داریم
حالا فرض کنید کلید ورودی تابع shard رو اینگونه تغییر بدیم
shard(country(request.ip), request.path)
طبیعتا تو این حالت خیلی sharding بهتری صورت میگیره
همین یه مثال ساده نشون میده که چقدر انتخاب کلید ورودی تابع هش میتونه موثر باشه در عملکرد سیستم shard شده و اگه کلید خوبی انتخاب نکنیم شاید عملا فقط دردسرهای خودمونو زیاد کرده باشیم و sharding تاثیر چندانی نداشته باشه تو بهبود عملکرد سیستم...
#designing_distributed_systems_brendan_burns
@gocasts
همونطور که در پست قبلی اشاره شد باید به تابع هش یک ورودی داده بشه، انتخاب اینکه ورودی تابع هش چی باشه خیلی مهمه.
فرض کنید بخوایم دو پارامتر ip و path (همون route درخواست) رو به عنوان ورودی تابع هش در نظر بگیریم:
shard(request.ip, request.path)
اتفاقی که میفته اینه که مثلا دو درخواست از یک کشور مثل فرانسه ممکنه به دو تا shard مختلف توزیع بشن که این اصلا خوب نیست، ما میخوایم دیتای موقعیت های جغرافیایی یکسان رو تو یه shard نگه داریم
حالا فرض کنید کلید ورودی تابع shard رو اینگونه تغییر بدیم
shard(country(request.ip), request.path)
طبیعتا تو این حالت خیلی sharding بهتری صورت میگیره
همین یه مثال ساده نشون میده که چقدر انتخاب کلید ورودی تابع هش میتونه موثر باشه در عملکرد سیستم shard شده و اگه کلید خوبی انتخاب نکنیم شاید عملا فقط دردسرهای خودمونو زیاد کرده باشیم و sharding تاثیر چندانی نداشته باشه تو بهبود عملکرد سیستم...
#designing_distributed_systems_brendan_burns
@gocasts
Go Casts 🚀
Selecting a Key همونطور که در پست قبلی اشاره شد باید به تابع هش یک ورودی داده بشه، انتخاب اینکه ورودی تابع هش چی باشه خیلی مهمه. فرض کنید بخوایم دو پارامتر ip و path (همون route درخواست) رو به عنوان ورودی تابع هش در نظر بگیریم: shard(request.ip, request.path)…
Consisten Hashing
تصور کنید که شما تصمیم میگیرید که تعداد node های shard رو تغییر بدید، سوال بزرگ اینه که چه بلایی بر سر hash key ها میاد؟ چون با کم و زیاد شدن node ها عملا خروجی تابع hash برای درخواست ها تغییر میکنه و درخواست ها به node درستی داده نمیشن.
این اتفاق اجتناب ناپذیره، اما یه سری الگوریتم های hashing هستن که تضمین میکنن با تغییر تعداد node ها فقط (#keys / #shards) تعداد از کلید ها احتیاج به remap شدن به shard جدید دارن و خیلی از کلید ها همچنان به node های قبلیشون map میشن.
این الگوریتم هارو consistent hashing میگن. مثلا تصور کنید اگه تعداد node های شما از ۱۰ به ۱۱ node تغییر کنه کمتر از ۱۰ درصد درخواست ها remap میشه که خب این خیلی اتفاق خوبیه، چون remap شدن منجر به repopulate شدن دیتای مورد نیاز درخواست در node جدید میشه که بسیار هزینه بر هست برای سیستم.
استفاده از consistent hashing در بسیاری از سیستم های توزیع شده رایجه و این اهمیت اینگونه الگوریتم ها رو میرسونه
این ویدیو کوتاه خیلی خوب توضیح داده
https://www.youtube.com/watch?v=zaRkONvyGr8
همچنین این مقاله خیلی خوب visualize کرده
https://www.toptal.com/big-data/consistent-hashing
آپدیت: اینم یه مقاله خوب و پیاده سازی در زبان گولنگ
https://medium.com/codex/understanding-and-implementing-consistent-hash-algorithm-e53a35afa428
#designing_distributed_systems_brendan_burns
@gocasts
تصور کنید که شما تصمیم میگیرید که تعداد node های shard رو تغییر بدید، سوال بزرگ اینه که چه بلایی بر سر hash key ها میاد؟ چون با کم و زیاد شدن node ها عملا خروجی تابع hash برای درخواست ها تغییر میکنه و درخواست ها به node درستی داده نمیشن.
این اتفاق اجتناب ناپذیره، اما یه سری الگوریتم های hashing هستن که تضمین میکنن با تغییر تعداد node ها فقط (#keys / #shards) تعداد از کلید ها احتیاج به remap شدن به shard جدید دارن و خیلی از کلید ها همچنان به node های قبلیشون map میشن.
این الگوریتم هارو consistent hashing میگن. مثلا تصور کنید اگه تعداد node های شما از ۱۰ به ۱۱ node تغییر کنه کمتر از ۱۰ درصد درخواست ها remap میشه که خب این خیلی اتفاق خوبیه، چون remap شدن منجر به repopulate شدن دیتای مورد نیاز درخواست در node جدید میشه که بسیار هزینه بر هست برای سیستم.
استفاده از consistent hashing در بسیاری از سیستم های توزیع شده رایجه و این اهمیت اینگونه الگوریتم ها رو میرسونه
این ویدیو کوتاه خیلی خوب توضیح داده
https://www.youtube.com/watch?v=zaRkONvyGr8
همچنین این مقاله خیلی خوب visualize کرده
https://www.toptal.com/big-data/consistent-hashing
آپدیت: اینم یه مقاله خوب و پیاده سازی در زبان گولنگ
https://medium.com/codex/understanding-and-implementing-consistent-hash-algorithm-e53a35afa428
#designing_distributed_systems_brendan_burns
@gocasts
YouTube
What is CONSISTENT HASHING and Where is it used?
Load Balancing is a key concept to system design. One of the popular ways to balance load in a system is to use the concept of consistent hashing. Consistent Hashing allows requests to be mapped into hash buckets while allowing the system to add and remove…
Go Casts 🚀
Consisten Hashing تصور کنید که شما تصمیم میگیرید که تعداد node های shard رو تغییر بدید، سوال بزرگ اینه که چه بلایی بر سر hash key ها میاد؟ چون با کم و زیاد شدن node ها عملا خروجی تابع hash برای درخواست ها تغییر میکنه و درخواست ها به node درستی داده نمیشن.…
Hot Sharding Systems
خیلی اوقات پیش میاد که لود shard های مختلف یکسان نیست و شما نمیتونید این موضوع رو مدیریت کنید
در اینگونه مواقع برای استفاده بهینه از منابع بهتره که از hot sharding استفاده بشه
به این صورت که در ابتدا به همه shard ها منابع یکسانی داده میشه از تعداد machine گرفته تا میزان RAM و CPU ولی به مرور زمان بر اساس لودی که به هر shard وارد میشه، این تخصیص منابع میتونه به صورت داینامیک عوض بشه و به shardی که لود بیشتری داره منابع بیشتری اختصاص داده بشه
#designing_distributed_systems_brendan_burns
@gocasts
خیلی اوقات پیش میاد که لود shard های مختلف یکسان نیست و شما نمیتونید این موضوع رو مدیریت کنید
در اینگونه مواقع برای استفاده بهینه از منابع بهتره که از hot sharding استفاده بشه
به این صورت که در ابتدا به همه shard ها منابع یکسانی داده میشه از تعداد machine گرفته تا میزان RAM و CPU ولی به مرور زمان بر اساس لودی که به هر shard وارد میشه، این تخصیص منابع میتونه به صورت داینامیک عوض بشه و به shardی که لود بیشتری داره منابع بیشتری اختصاص داده بشه
#designing_distributed_systems_brendan_burns
@gocasts
👍1
Go Casts 🚀
Consisten Hashing تصور کنید که شما تصمیم میگیرید که تعداد node های shard رو تغییر بدید، سوال بزرگ اینه که چه بلایی بر سر hash key ها میاد؟ چون با کم و زیاد شدن node ها عملا خروجی تابع hash برای درخواست ها تغییر میکنه و درخواست ها به node درستی داده نمیشن.…
دوستان پیشنهاد میکنم حتما بعد از خوندن پست های مربوط به الگوی Sharding این ویدیوی کوتاه در مورد Consistent Hashing رو ببینید
تو دنیای مدرن امروز عملا همه چیز حاضر و آماده شده، و برای استفاده از این الگوها، فقط کافیه که نحوه استفاده و محل استفاده رو بلد باشید...
منظورم از این حرف اینه که اگه الگویی کمی پیچیده میشه اصلا ازش نترسید، یا دور نشید ازش، بلکه با کمی آشنایی با کلیات اون الگو میتونید خیلی راحت به کمک ابزارهای موجود توی طراحی سیستمتون استفاده کنید ازش
این الگوی replicated و shardedی که من بحث کردم عملا تو خیلی از load balancer های معروف وجود داره و با چند خط کانفیگ میتونید به راحتی ازش استفاده کنید، مثلا در nginx به این شکله
upstream backend {
hash $request_uri consistent
server web-shard-1.web;
server web-shard-2.web;
server web-shard-3.web;
}
قطعا استفاده از این الگوهای ملاحظات دیگه ای هم داره که باید خودتون با توجه به بیزینستون بهش فکر کنید، اما وقتی قسمت سخت تر قضیه اینقدر راحت توسط ابزارهای موجود مدیریت میشه، مدیریت قسمت های ساده ترش توسط خود شما اصلا کار ترسناکی نخواهد بود
#designing_distributed_systems_brendan_burns
@gocasts
تو دنیای مدرن امروز عملا همه چیز حاضر و آماده شده، و برای استفاده از این الگوها، فقط کافیه که نحوه استفاده و محل استفاده رو بلد باشید...
منظورم از این حرف اینه که اگه الگویی کمی پیچیده میشه اصلا ازش نترسید، یا دور نشید ازش، بلکه با کمی آشنایی با کلیات اون الگو میتونید خیلی راحت به کمک ابزارهای موجود توی طراحی سیستمتون استفاده کنید ازش
این الگوی replicated و shardedی که من بحث کردم عملا تو خیلی از load balancer های معروف وجود داره و با چند خط کانفیگ میتونید به راحتی ازش استفاده کنید، مثلا در nginx به این شکله
upstream backend {
hash $request_uri consistent
server web-shard-1.web;
server web-shard-2.web;
server web-shard-3.web;
}
قطعا استفاده از این الگوهای ملاحظات دیگه ای هم داره که باید خودتون با توجه به بیزینستون بهش فکر کنید، اما وقتی قسمت سخت تر قضیه اینقدر راحت توسط ابزارهای موجود مدیریت میشه، مدیریت قسمت های ساده ترش توسط خود شما اصلا کار ترسناکی نخواهد بود
#designing_distributed_systems_brendan_burns
@gocasts
Go Casts 🚀
دوستان پیشنهاد میکنم حتما بعد از خوندن پست های مربوط به الگوی Sharding این ویدیوی کوتاه در مورد Consistent Hashing رو ببینید تو دنیای مدرن امروز عملا همه چیز حاضر و آماده شده، و برای استفاده از این الگوها، فقط کافیه که نحوه استفاده و محل استفاده رو بلد باشید...…
نکته آخری که میخوام بهش اشاره کنم اینه که شاید بپرسید الگوهایی مثل الگوی Sharded برای scale خیلی بالاست و احتمال خیلی زیاد شما تو کارتون بهش نیاز ندارید.
جواب کوتاه من میشه:خیر. دلیل من هم اینه که با رشد تکنولوژی، بسترهای ارائه خدمات خیلی پیچیده تر و اصطلاحا data-intensive تر شدن، به عنوان مثال الان دیگه messaging فقط برای چت کردن نیست، بلکه messaging یک platform شده برای کلی خدمات دیگه مثل آموزش، کسب و کار و غیره.
یا مثلا سرویس های ویدیویی در این دو سه ساله رشد بسیار زیادی داشتن مخصوصا پس از پاندمی کرونا. خود بلاکچین و پلتفرم های مبتنی بر هوش مصنوعی و iot هم ذاتا data-intensive هستن.
وقتی میگیم data-intensive یعنی اینکه حجم دیتایی که شما باید مدیریت کنید ذاتا زیاده (اگه الان نیست بزودی میشه). پس باید از قبل خودتون رو برای اون روز آماده کنید، که اگه به فکر scale نباشید و اصولش رو رعایت نکنید، چالش های زیادی در آینده خواهید داشت.
من اصلا منظورم این نیست که در لحظه کاری که میکنید رو خیلی over-engineering کنید، نه اصلا، بلکه هدفم اینه که توی طراحی و دیزاین حتما نیم نگاهی به این قضیه داشته باشید و به این فکر کنید که با طراحی فعلی اگه قرار باشه سیستم scale پیدا کنه، آیا سیستم پاسخگو هست یا خیر، آیا میتونید دیتابیس رو shard کنید بصورت موثر یا خیر.
شاید خوندن مقاله ای از تیم Notion که اخیرا درگیر این چالش بودن مفید باشه، که یکی از مواردی که بهش اشاره میکنه Shard earlier هست، و میگه که ای کاش زودتر به این فکر بودیم...
https://www.notion.so/blog/sharding-postgres-at-notion
دمتون گرم، یا علی
#designing_distributed_systems_brendan_burns
@gocasts
جواب کوتاه من میشه:خیر. دلیل من هم اینه که با رشد تکنولوژی، بسترهای ارائه خدمات خیلی پیچیده تر و اصطلاحا data-intensive تر شدن، به عنوان مثال الان دیگه messaging فقط برای چت کردن نیست، بلکه messaging یک platform شده برای کلی خدمات دیگه مثل آموزش، کسب و کار و غیره.
یا مثلا سرویس های ویدیویی در این دو سه ساله رشد بسیار زیادی داشتن مخصوصا پس از پاندمی کرونا. خود بلاکچین و پلتفرم های مبتنی بر هوش مصنوعی و iot هم ذاتا data-intensive هستن.
وقتی میگیم data-intensive یعنی اینکه حجم دیتایی که شما باید مدیریت کنید ذاتا زیاده (اگه الان نیست بزودی میشه). پس باید از قبل خودتون رو برای اون روز آماده کنید، که اگه به فکر scale نباشید و اصولش رو رعایت نکنید، چالش های زیادی در آینده خواهید داشت.
من اصلا منظورم این نیست که در لحظه کاری که میکنید رو خیلی over-engineering کنید، نه اصلا، بلکه هدفم اینه که توی طراحی و دیزاین حتما نیم نگاهی به این قضیه داشته باشید و به این فکر کنید که با طراحی فعلی اگه قرار باشه سیستم scale پیدا کنه، آیا سیستم پاسخگو هست یا خیر، آیا میتونید دیتابیس رو shard کنید بصورت موثر یا خیر.
شاید خوندن مقاله ای از تیم Notion که اخیرا درگیر این چالش بودن مفید باشه، که یکی از مواردی که بهش اشاره میکنه Shard earlier هست، و میگه که ای کاش زودتر به این فکر بودیم...
https://www.notion.so/blog/sharding-postgres-at-notion
دمتون گرم، یا علی
#designing_distributed_systems_brendan_burns
@gocasts
Notion
Herding elephants: lessons learned from sharding Postgres at Notion
With an effort to make Notion faster and more reliable for years to come — we migrated Notion’s PostgreSQL monolith into a horizontally-partitioned database fleet.
Go Casts 🚀
Introduction to Microservices در سال های اخیر عبارت «microservices» برای توصیف multi-node distributed software archetectures یک عبارت همه گیر شده است. عموما Microservices سیستمی را توصیف می کنه که از چند component مختلف تشکیل شده که هر کدام از این component…
در مورد مفاهیم Microservice و SOA بحث جالبی با آقای حکایتی شکل گرفت که در کامنت های این پست میتونید مطالعه کنید.
https://news.1rj.ru/str/c/1525472919/105
https://news.1rj.ru/str/c/1525472919/106
https://news.1rj.ru/str/c/1525472919/107
https://news.1rj.ru/str/c/1525472919/105
https://news.1rj.ru/str/c/1525472919/106
https://news.1rj.ru/str/c/1525472919/107
Go Casts 🚀
نکته آخری که میخوام بهش اشاره کنم اینه که شاید بپرسید الگوهایی مثل الگوی Sharded برای scale خیلی بالاست و احتمال خیلی زیاد شما تو کارتون بهش نیاز ندارید. جواب کوتاه من میشه:خیر. دلیل من هم اینه که با رشد تکنولوژی، بسترهای ارائه خدمات خیلی پیچیده تر و اصطلاحا…
سلام دوستان، امیدوارم حالتون خوب باشه، من باز اومدم با یه الگوی دیگه از دنیای distributed systems!
Scatter/Gather
الگوی بعدی که در موردش صحبت میکنیم، الگوی scatter/gather هست.
الگوی replicated از منظر «تعداد درخواست پردازش شده در ثانیه» به scalability توجه میکنه.
الگوی sharded از منظر «حجم دیتا» به scalability توجه میکنه.
الگوی scatter/gather با استفاده از الگوی replication از منظر «زمان» به scalability توجه میکنه.
خیلی ساده تر بخوام بگم این الگو موازی سازی(parallelism) رو امکانپذیر میکنه. به این صورت که اجازه میده به درخواست ها خیلی سریعتر از حالت sequential پاسخ بدید.
الگوی scatter/gather هم مثل الگوهای replicated و sharded یک الگوی درختی هست.
یعنی یک نود root داره که درخواست هارو به نودهای برگ میده و اونا پردازش میکنن.
اما این الگو یه تفاوت بزرگ و مهم با دو الگوی قبلی داره، اونم اینه که بصورت همزمان درخواست ورودی رو به همه ی نودهای برگ میفرسته و هر کدوم از اون نود ها مسئول پردازش بخش کوچیکی از دیتا هستند. هر نود برگ (leaf) بخشی از نتیجه رو به نود ریشه(root) برمیگردونه و نود ریشه بعد از ترکیب کردن همه نتایج یک جواب کامل رو به عنوان پاسخ برای درخواست ارسال میکنه.
#designing_distributed_systems_brendan_burns
@gocasts
Scatter/Gather
الگوی بعدی که در موردش صحبت میکنیم، الگوی scatter/gather هست.
الگوی replicated از منظر «تعداد درخواست پردازش شده در ثانیه» به scalability توجه میکنه.
الگوی sharded از منظر «حجم دیتا» به scalability توجه میکنه.
الگوی scatter/gather با استفاده از الگوی replication از منظر «زمان» به scalability توجه میکنه.
خیلی ساده تر بخوام بگم این الگو موازی سازی(parallelism) رو امکانپذیر میکنه. به این صورت که اجازه میده به درخواست ها خیلی سریعتر از حالت sequential پاسخ بدید.
الگوی scatter/gather هم مثل الگوهای replicated و sharded یک الگوی درختی هست.
یعنی یک نود root داره که درخواست هارو به نودهای برگ میده و اونا پردازش میکنن.
اما این الگو یه تفاوت بزرگ و مهم با دو الگوی قبلی داره، اونم اینه که بصورت همزمان درخواست ورودی رو به همه ی نودهای برگ میفرسته و هر کدوم از اون نود ها مسئول پردازش بخش کوچیکی از دیتا هستند. هر نود برگ (leaf) بخشی از نتیجه رو به نود ریشه(root) برمیگردونه و نود ریشه بعد از ترکیب کردن همه نتایج یک جواب کامل رو به عنوان پاسخ برای درخواست ارسال میکنه.
#designing_distributed_systems_brendan_burns
@gocasts
Go Casts 🚀
سلام دوستان، امیدوارم حالتون خوب باشه، من باز اومدم با یه الگوی دیگه از دنیای distributed systems! Scatter/Gather الگوی بعدی که در موردش صحبت میکنیم، الگوی scatter/gather هست. الگوی replicated از منظر «تعداد درخواست پردازش شده در ثانیه» به scalability توجه…
الگوی scatter/gather وقتی خیلی کارآمد هست که شما حجم بسیار زیادی از داده های مستقل از همدیگه رو برای پاسخگویی به درخواست کاربر لازم دارید.
درواقع اگه بخوایم تفاوت الگوی scatterh/gather رو با الگوی sharding بگیم، اینطوری میشه که الگوی sharded هدفش تقسیم(shard) کردن داده هاست اما الگوی scatter/gather هدفش تقسیم کردن حجم محاسبات (computation) هست.
تو این الگو هر نود برگ مسئول «پردازش» بخشی از داده هاست
#designing_distributed_systems_brendan_burns
@gocasts
درواقع اگه بخوایم تفاوت الگوی scatterh/gather رو با الگوی sharding بگیم، اینطوری میشه که الگوی sharded هدفش تقسیم(shard) کردن داده هاست اما الگوی scatter/gather هدفش تقسیم کردن حجم محاسبات (computation) هست.
تو این الگو هر نود برگ مسئول «پردازش» بخشی از داده هاست
#designing_distributed_systems_brendan_burns
@gocasts
Go Casts 🚀
الگوی scatter/gather وقتی خیلی کارآمد هست که شما حجم بسیار زیادی از داده های مستقل از همدیگه رو برای پاسخگویی به درخواست کاربر لازم دارید. درواقع اگه بخوایم تفاوت الگوی scatterh/gather رو با الگوی sharding بگیم، اینطوری میشه که الگوی sharded هدفش تقسیم(shard)…
Scatter/Gather with Root Distribution
تو این نوع پیاده سازی، همه نودهای برگ به همه دیتا دسترسی دارند، و نود root پاسخگویی به هر بخش از دیتا رو به یک نود خاص واگذار میکنه.
Hands On: Distributed Document Search
مثلا برای جستجو در دیتابیس مجموعه ای از documentها، اگه همه نودهای برگ به همه documentها دسترسی داشته باشن، و مثلا درخواست ورودی پیدا کردن همه document های که شامل دو کلمه Cat و Dog باشه، نود root به یک نود میگه همه داکیومنت هایی رو پیدا کن که کلمه Cat دارند، و به یک نود دیگه میگه همه document هایی رو پیدا کن که کلمه Dog دارند، نود root بعد از گرفتن هر دو لیست، آیتم های مشترک هر دو لیست رو به عنوان پاسخ به درخواست ارسال میکنه
#designing_distributed_systems_brendan_burns
@gocasts
تو این نوع پیاده سازی، همه نودهای برگ به همه دیتا دسترسی دارند، و نود root پاسخگویی به هر بخش از دیتا رو به یک نود خاص واگذار میکنه.
Hands On: Distributed Document Search
مثلا برای جستجو در دیتابیس مجموعه ای از documentها، اگه همه نودهای برگ به همه documentها دسترسی داشته باشن، و مثلا درخواست ورودی پیدا کردن همه document های که شامل دو کلمه Cat و Dog باشه، نود root به یک نود میگه همه داکیومنت هایی رو پیدا کن که کلمه Cat دارند، و به یک نود دیگه میگه همه document هایی رو پیدا کن که کلمه Dog دارند، نود root بعد از گرفتن هر دو لیست، آیتم های مشترک هر دو لیست رو به عنوان پاسخ به درخواست ارسال میکنه
#designing_distributed_systems_brendan_burns
@gocasts
Go Casts 🚀
Scatter/Gather with Root Distribution تو این نوع پیاده سازی، همه نودهای برگ به همه دیتا دسترسی دارند، و نود root پاسخگویی به هر بخش از دیتا رو به یک نود خاص واگذار میکنه. Hands On: Distributed Document Search مثلا برای جستجو در دیتابیس مجموعه ای از documentها،…
Scatter/Gather with Leaf Sharding
وقتی حجم دیتا خیلی زیاد باشه، شما نمیتونید همه دیتا رو روی همه node ها داشته باشید. راه حلش اینه که هر node فقط یه قسمتی از دیتا رو داشته باشه، و نود root از هر نود برگ بخواد به همه درخواست رسیدگی کنه.
تو مثال بالا اینطوری میشه که هر نود مستقلا به دنبال همه document هایی میگرده که حتما دو کلمه cat و dog رو با هم داشته باشن. وظیفه نود ریشه این میشه که همه لیست هارو با هم جمع کنه و به عنوان پاسخ برگردونه.
تو حالت قبلی دیتا shard نبود و درخواست shard شد، تو این حالت دیتا shard هست و درخواست بصورت کامل به همه داده میشه
#designing_distributed_systems_brendan_burns
@gocasts
وقتی حجم دیتا خیلی زیاد باشه، شما نمیتونید همه دیتا رو روی همه node ها داشته باشید. راه حلش اینه که هر node فقط یه قسمتی از دیتا رو داشته باشه، و نود root از هر نود برگ بخواد به همه درخواست رسیدگی کنه.
تو مثال بالا اینطوری میشه که هر نود مستقلا به دنبال همه document هایی میگرده که حتما دو کلمه cat و dog رو با هم داشته باشن. وظیفه نود ریشه این میشه که همه لیست هارو با هم جمع کنه و به عنوان پاسخ برگردونه.
تو حالت قبلی دیتا shard نبود و درخواست shard شد، تو این حالت دیتا shard هست و درخواست بصورت کامل به همه داده میشه
#designing_distributed_systems_brendan_burns
@gocasts
🔥1
Go Casts 🚀
Scatter/Gather with Leaf Sharding وقتی حجم دیتا خیلی زیاد باشه، شما نمیتونید همه دیتا رو روی همه node ها داشته باشید. راه حلش اینه که هر node فقط یه قسمتی از دیتا رو داشته باشه، و نود root از هر نود برگ بخواد به همه درخواست رسیدگی کنه. تو مثال بالا اینطوری…
Choosing the Right Number of Leaves
خب حالا که مزایای موازی سازی رو متوجه شدیم، سوال اصلی اینه که چه تعداد نود برگ برای سیستم در نظر بگیریم، شاید در نگاه اول اینطور به نظر بیاد که هر چه تعداد نودهای برگ بیشتر بشه سریعتر میشه با درخواست ها پاسخ گفت، اما اینطور نیست...
باید در نظر داشته باشید که distribute کردن هر درخواست بین نودهای مختلف overheadهایی داره، مثل parse کردن درخواست های http و ارسال درخواست روی شبکه
همچنی یه مساله ای هست که به «straggler problem» معروفه. مساله چیه؟ در الگوی scatter/gather مدت زمان پاسخگویی به اندازه سرعت کندترین نود هست، پس اگه شما ۵ تا نود با حداکثر ۵ میلی ثانیه latency داشته باشید خیلی بهتره از داشتن ۱۰۰ تا نود با حداکثر ۲۰ میلی ثانیه latency. به این نکته توجه کنید که هر چه تعداد node ها بیشتر بشه احتمال اینکه یه نود با latency بالا وجود داشته باشه بیشتره..
#designing_distributed_systems_brendan_burns
@gocasts
خب حالا که مزایای موازی سازی رو متوجه شدیم، سوال اصلی اینه که چه تعداد نود برگ برای سیستم در نظر بگیریم، شاید در نگاه اول اینطور به نظر بیاد که هر چه تعداد نودهای برگ بیشتر بشه سریعتر میشه با درخواست ها پاسخ گفت، اما اینطور نیست...
باید در نظر داشته باشید که distribute کردن هر درخواست بین نودهای مختلف overheadهایی داره، مثل parse کردن درخواست های http و ارسال درخواست روی شبکه
همچنی یه مساله ای هست که به «straggler problem» معروفه. مساله چیه؟ در الگوی scatter/gather مدت زمان پاسخگویی به اندازه سرعت کندترین نود هست، پس اگه شما ۵ تا نود با حداکثر ۵ میلی ثانیه latency داشته باشید خیلی بهتره از داشتن ۱۰۰ تا نود با حداکثر ۲۰ میلی ثانیه latency. به این نکته توجه کنید که هر چه تعداد node ها بیشتر بشه احتمال اینکه یه نود با latency بالا وجود داشته باشه بیشتره..
#designing_distributed_systems_brendan_burns
@gocasts
Go Casts 🚀
Choosing the Right Number of Leaves خب حالا که مزایای موازی سازی رو متوجه شدیم، سوال اصلی اینه که چه تعداد نود برگ برای سیستم در نظر بگیریم، شاید در نگاه اول اینطور به نظر بیاد که هر چه تعداد نودهای برگ بیشتر بشه سریعتر میشه با درخواست ها پاسخ گفت، اما اینطور…
بیاید با هم فکر کنیم مثلا چه use-case هایی میشه واسه این الگو پیدا کرد!
اگه بخوام مثالی بزنم که این الگو کارآمد باشه شاید بشه سیستم هایی که با نقشه سر و کار دارند رو مثال زد. چون تو این سیستم ها حجم داده ذاتا زیاده و در عین حال حجم محاسباتی که real-time هم باید صورت بگیره زیاده.
مثلا مسیریابی بین دو نقطه مبدا و مقصد رو در نظر بگیرید:
- حجم دیتایی که باید پردازش بشه که با در نظر گرفتن شرایط ترافیک و غیره بخواد مسیر بهینه رو به شما پیشنهاد بده خیلی زیاده.
- انجام محاسبات بین دو نقطه میانی (برای یافتن مسیر بهینه محلی) مستقل از شرایط نقاط دیگه است
خب چیکار میشه کرد که خیلی سریع بشه مسیر بهینه رو پیدا کرد؟
میشه یک سری نقاط میانی تعیین کرد، یافتن مسیر بهینه بین هر دو نقطه میانی رو به یک node واگذار کرد. هر node پس از انجام محاسبات اطلاعات مسیر رو به نود root برمیگردونه. نود root با استفاده از اطلاعات نقاط میانی و از ترکیب اون ها میتونه یه مسیر بهینه رو به عنوان پاسخ به شما پیشنهاد بده.
البته من تجربه کار با چنین سرویس هایی رو نداشتم، و قطعا ملاحظات خیلی بیشتری در این سیستم ها باید در نظر گرفته بشه، اما فکر میکنم این الگو بتونه در حل چالش چنین مساله ای کمک کنه!
#designing_distributed_systems_brendan_burns
@gocasts
اگه بخوام مثالی بزنم که این الگو کارآمد باشه شاید بشه سیستم هایی که با نقشه سر و کار دارند رو مثال زد. چون تو این سیستم ها حجم داده ذاتا زیاده و در عین حال حجم محاسباتی که real-time هم باید صورت بگیره زیاده.
مثلا مسیریابی بین دو نقطه مبدا و مقصد رو در نظر بگیرید:
- حجم دیتایی که باید پردازش بشه که با در نظر گرفتن شرایط ترافیک و غیره بخواد مسیر بهینه رو به شما پیشنهاد بده خیلی زیاده.
- انجام محاسبات بین دو نقطه میانی (برای یافتن مسیر بهینه محلی) مستقل از شرایط نقاط دیگه است
خب چیکار میشه کرد که خیلی سریع بشه مسیر بهینه رو پیدا کرد؟
میشه یک سری نقاط میانی تعیین کرد، یافتن مسیر بهینه بین هر دو نقطه میانی رو به یک node واگذار کرد. هر node پس از انجام محاسبات اطلاعات مسیر رو به نود root برمیگردونه. نود root با استفاده از اطلاعات نقاط میانی و از ترکیب اون ها میتونه یه مسیر بهینه رو به عنوان پاسخ به شما پیشنهاد بده.
البته من تجربه کار با چنین سرویس هایی رو نداشتم، و قطعا ملاحظات خیلی بیشتری در این سیستم ها باید در نظر گرفته بشه، اما فکر میکنم این الگو بتونه در حل چالش چنین مساله ای کمک کنه!
#designing_distributed_systems_brendan_burns
@gocasts
سلام دوستان، معمولا یکی از کارهایی که خیلی دوست دارم و در عین حال به عمیق شدن دانشم خیلی کمک میکنه اینه که فارغ از فضای مجازی پیرامونم که پر شده از مطالب کاملا سطحی و بی ارزش، سعی می کنم برم دنبال آدمایی بگردم که واقعا از نظر علمی و تخصصی خیلی جایگاه بالایی دارن و در عین حال دانششون رو با دیگران به اشتراک میذارن.
پیدا کردن اینجور آدما خیلی سخته، چون اونا برای دیده شدن مطلب نمینویسن و براشون هم کمیت مخاطبین مهم نیست، خیلی اوقات اینطور آدم هارو اتفاقی پیدا میکنم ولی وقتی پیداشون میکنم سعی می کنم هر آنچه که ارائه دادند رو برای خودم جمع آوری کنم، حتی اگه نتونم در لحظه همه مطالب رو بخونم سعی می کنم با یه فعالیت جمع آوری دقیق همه چیز رو برای خودم ایندکس کنم، خیلی وقت ها پیش اومده در یه زمان دیگه ای اون مطلب به شدت به کارم اومده
افسوس که به خاطر مشغله های کاری خودم فرصت کمی دارم برای پرداختن به این دست فعالیت ها، اما اگه شما فرصتشو دارید حتما سعی کنید مطالبشون رو دنبال کنید که بی نهایت به عمیق شدن دانشتون کمک میکنه
اینارو گفتم که امروز آقای Ian Lance Taylor رو به شما معرفی کنیم، ایشون از اوایل دهه ۹۰ میلادی روی gcc کار میکنه و کسی هست که gccgo رو از همون سال ۲۰۰۹ شروع کرده به ساختن.
اگه نمیدونید gccgo چی هست میشه gcc frontend for go language، که میشه کامپایلر غیر رسمی go روی gcc
در اینکه عملکرد gccgo بدتر از خود gc رسمی گولنگ هست شکی نیست، اما چون عملکرد gccgo بدتره دلیل نمیشه در موردش نخونید، با دنبال کردن مطالب و باگ و چالش هاش، کلی مطلب مفید در مورد زبان گولنگ و عملکرد کامپایلرها یاد میگیرد.
برای اطلاعات بیشتر در مورد gccgo میتونید لینک های زیر رو ببینید
https://gcc.gnu.org/onlinedocs/gccgo/
https://meltware.com/2019/01/16/gccgo-benchmarks-2019.html
https://stackoverflow.com/questions/25811445/what-are-the-primary-differences-between-gc-and-gccgo#:~:text=Compared%20to%20gc%2C%20gccgo%20is,the%20processors%20that%20GCC%20supports.
https://golang.org/doc/install/gccgo
در نهایت میخوام پست های آقای Ian Lance Taylor که در مورد golang هست رو به شما معرفی کنم، اکثر پست ها مربوط به سال های ۲۰۰۹ و ۲۰۱۰ هست و با خوندنش دید بهتری نسبت به go internal خواهید داشت قطعا.
Go
https://www.airs.com/blog/archives/273
Go Channels
https://www.airs.com/blog/archives/275
Go Interfaces
https://www.airs.com/blog/archives/277
Go Interface Values
https://www.airs.com/blog/archives/281
Go New/Make
https://www.airs.com/blog/archives/283
A GCC Frontend
https://www.airs.com/blog/archives/287
Generics
https://www.airs.com/blog/archives/291
Go Linkage Names
https://www.airs.com/blog/archives/309
Thread Sanitizer
https://www.airs.com/blog/archives/321
Signed or Unsinged
https://www.airs.com/blog/archives/327
Software Paradigms
https://www.airs.com/blog/archives/342
Container Models
https://www.airs.com/blog/archives/349
Destructors
https://www.airs.com/blog/archives/362
gccgo panic/recover
https://www.airs.com/blog/archives/376
GCC Summit
https://www.airs.com/blog/archives/435
Versioning
https://www.airs.com/blog/archives/442
Gccgo in GCC
https://www.airs.com/blog/archives/448
Race Conditions
https://www.airs.com/blog/archives/482
Go experience report: the append function
https://www.airs.com/blog/archives/559
#the_right_person
#golang #gcc
#go_internal
@gocasts
پیدا کردن اینجور آدما خیلی سخته، چون اونا برای دیده شدن مطلب نمینویسن و براشون هم کمیت مخاطبین مهم نیست، خیلی اوقات اینطور آدم هارو اتفاقی پیدا میکنم ولی وقتی پیداشون میکنم سعی می کنم هر آنچه که ارائه دادند رو برای خودم جمع آوری کنم، حتی اگه نتونم در لحظه همه مطالب رو بخونم سعی می کنم با یه فعالیت جمع آوری دقیق همه چیز رو برای خودم ایندکس کنم، خیلی وقت ها پیش اومده در یه زمان دیگه ای اون مطلب به شدت به کارم اومده
افسوس که به خاطر مشغله های کاری خودم فرصت کمی دارم برای پرداختن به این دست فعالیت ها، اما اگه شما فرصتشو دارید حتما سعی کنید مطالبشون رو دنبال کنید که بی نهایت به عمیق شدن دانشتون کمک میکنه
اینارو گفتم که امروز آقای Ian Lance Taylor رو به شما معرفی کنیم، ایشون از اوایل دهه ۹۰ میلادی روی gcc کار میکنه و کسی هست که gccgo رو از همون سال ۲۰۰۹ شروع کرده به ساختن.
اگه نمیدونید gccgo چی هست میشه gcc frontend for go language، که میشه کامپایلر غیر رسمی go روی gcc
در اینکه عملکرد gccgo بدتر از خود gc رسمی گولنگ هست شکی نیست، اما چون عملکرد gccgo بدتره دلیل نمیشه در موردش نخونید، با دنبال کردن مطالب و باگ و چالش هاش، کلی مطلب مفید در مورد زبان گولنگ و عملکرد کامپایلرها یاد میگیرد.
برای اطلاعات بیشتر در مورد gccgo میتونید لینک های زیر رو ببینید
https://gcc.gnu.org/onlinedocs/gccgo/
https://meltware.com/2019/01/16/gccgo-benchmarks-2019.html
https://stackoverflow.com/questions/25811445/what-are-the-primary-differences-between-gc-and-gccgo#:~:text=Compared%20to%20gc%2C%20gccgo%20is,the%20processors%20that%20GCC%20supports.
https://golang.org/doc/install/gccgo
در نهایت میخوام پست های آقای Ian Lance Taylor که در مورد golang هست رو به شما معرفی کنم، اکثر پست ها مربوط به سال های ۲۰۰۹ و ۲۰۱۰ هست و با خوندنش دید بهتری نسبت به go internal خواهید داشت قطعا.
Go
https://www.airs.com/blog/archives/273
Go Channels
https://www.airs.com/blog/archives/275
Go Interfaces
https://www.airs.com/blog/archives/277
Go Interface Values
https://www.airs.com/blog/archives/281
Go New/Make
https://www.airs.com/blog/archives/283
A GCC Frontend
https://www.airs.com/blog/archives/287
Generics
https://www.airs.com/blog/archives/291
Go Linkage Names
https://www.airs.com/blog/archives/309
Thread Sanitizer
https://www.airs.com/blog/archives/321
Signed or Unsinged
https://www.airs.com/blog/archives/327
Software Paradigms
https://www.airs.com/blog/archives/342
Container Models
https://www.airs.com/blog/archives/349
Destructors
https://www.airs.com/blog/archives/362
gccgo panic/recover
https://www.airs.com/blog/archives/376
GCC Summit
https://www.airs.com/blog/archives/435
Versioning
https://www.airs.com/blog/archives/442
Gccgo in GCC
https://www.airs.com/blog/archives/448
Race Conditions
https://www.airs.com/blog/archives/482
Go experience report: the append function
https://www.airs.com/blog/archives/559
#the_right_person
#golang #gcc
#go_internal
@gocasts
gcc.gnu.org
Introduction ¶
Next: GNU General Public License [Contents][Index]
این ویدیو به زیبایی هر چه تمام تر انواع consistency model هارو توضیح میده، مخصوصا eventual consistency رو که در سیستم های توزیع شده خیلی استفاده میشه.
https://www.youtube.com/watch?v=Fm8iUFM2iWU&list=WL&index=6
آقای Chris Colohan بیش از ۱۰ سال در گوگل روی ساخت انواع سیستم های توزیع شده کار کردند و درسی رو به رایگان ارائه میدن به همین نام که میتونید مطالبش رو از این لینک دنبال کنید
http://www.distributedsystemscourse.com
@gocasts
https://www.youtube.com/watch?v=Fm8iUFM2iWU&list=WL&index=6
آقای Chris Colohan بیش از ۱۰ سال در گوگل روی ساخت انواع سیستم های توزیع شده کار کردند و درسی رو به رایگان ارائه میدن به همین نام که میتونید مطالبش رو از این لینک دنبال کنید
http://www.distributedsystemscourse.com
@gocasts
YouTube
L17: Consistency Models in Distributed Systems
What does it mean when someone talks about "consistency models", or "relaxed consistency"? Here we review what it means to keep data consistent in a distributed system, covering strict consistency, sequential consistency, FIFO consistency (a.k.a. PRAM consistency)…
سلام دوستان وقت بخیر
احتمالا اسم آقای Bill Kenedy به گوشتون خورده باشه، ایشون یکی از بهترین اساتیدی هستند که گولنگ رو آموزش میدن، اخیرا هم کتاب Ultimate GO رو منتشر کردن که مباحث خیلی پیشرفته ای رو در زمینه گولنگ پوشش میده.
احتمالا با برخی از مقالات خیلی خوبشون که تحت بلاگ Ardan labs هم منتشر میشه آشنا هستید.
قراره که ان شاءالله روز ۱۲ آبان ساعت ۱۸ و ۳۰ به وقت تهران یک meetup یک ساعته با ایشون داشته باشیم، خیلی خوشحال میشم اگه در کامنت های همین پست موضوعاتی که دوست دارید در جلسه پوشش داده بشه رو ذکر کنید.
https://twitter.com/goinggodotnet
https://www.ardanlabs.com/blog/
https://courses.ardanlabs.com
@gocasts
احتمالا اسم آقای Bill Kenedy به گوشتون خورده باشه، ایشون یکی از بهترین اساتیدی هستند که گولنگ رو آموزش میدن، اخیرا هم کتاب Ultimate GO رو منتشر کردن که مباحث خیلی پیشرفته ای رو در زمینه گولنگ پوشش میده.
احتمالا با برخی از مقالات خیلی خوبشون که تحت بلاگ Ardan labs هم منتشر میشه آشنا هستید.
قراره که ان شاءالله روز ۱۲ آبان ساعت ۱۸ و ۳۰ به وقت تهران یک meetup یک ساعته با ایشون داشته باشیم، خیلی خوشحال میشم اگه در کامنت های همین پست موضوعاتی که دوست دارید در جلسه پوشش داده بشه رو ذکر کنید.
https://twitter.com/goinggodotnet
https://www.ardanlabs.com/blog/
https://courses.ardanlabs.com
@gocasts
X (formerly Twitter)
William (Bill) Kennedy (@goinggodotnet) on X
⌯Go: Walking the line between correctness and comprehension ⦁ bill@ardanlabs.com ⦁ Wife(@aleintech) ⦁ NPO(@golangbridge) ⦁ GMT-5(MIA)
Go Casts 🚀
سلام دوستان وقت بخیر احتمالا اسم آقای Bill Kenedy به گوشتون خورده باشه، ایشون یکی از بهترین اساتیدی هستند که گولنگ رو آموزش میدن، اخیرا هم کتاب Ultimate GO رو منتشر کردن که مباحث خیلی پیشرفته ای رو در زمینه گولنگ پوشش میده. احتمالا با برخی از مقالات خیلی خوبشون…
موضوع جلسه چی باشه؟
هدف اصلی من از این جلسه آشنایی ایشون با کامیونیتی ایرانه و فعالیت هایی که میشه تا یه موضوع خاص..
@gocasts
هدف اصلی من از این جلسه آشنایی ایشون با کامیونیتی ایرانه و فعالیت هایی که میشه تا یه موضوع خاص..
@gocasts
Go Casts 🚀
Voice message
سلام دوستان
موضوعاتی که فعلا پیشنهاد شده که میتونه یک یا چند تا از این ها باشه بسته به مدت زمان بحث، این ها هستند:
- ویژگی های cloud-native application و چرا گولنگ زبان مناسبیه
- تطبیق ویژگی های oop از زبان های قدیمی با گولنگ برای افرادی که از این زبان ها مهاجرت می کنند و مشکلات مرتبط
- بحث جنریک و نگرانی ها بابت generic pollution
- چه مباحثی مهم هستند برای اینکه تبدیل به یه go engineer بهتر بشیم
- ویژگی های یک microservice حرفه ای (چیزی که در دوره های آموزشی تبلیغ میشه توسط ایشون)
اگه در مورد این موضوعات نکته ای مد نظرتون هست حتما تو کامنت ها در موردش بحث کنیم
@gocasts
موضوعاتی که فعلا پیشنهاد شده که میتونه یک یا چند تا از این ها باشه بسته به مدت زمان بحث، این ها هستند:
- ویژگی های cloud-native application و چرا گولنگ زبان مناسبیه
- تطبیق ویژگی های oop از زبان های قدیمی با گولنگ برای افرادی که از این زبان ها مهاجرت می کنند و مشکلات مرتبط
- بحث جنریک و نگرانی ها بابت generic pollution
- چه مباحثی مهم هستند برای اینکه تبدیل به یه go engineer بهتر بشیم
- ویژگی های یک microservice حرفه ای (چیزی که در دوره های آموزشی تبلیغ میشه توسط ایشون)
اگه در مورد این موضوعات نکته ای مد نظرتون هست حتما تو کامنت ها در موردش بحث کنیم
@gocasts
👍1