Функція гарантована, щоб ніколи не повертати одне і те ж значення двічі [закрито]

Це питання, яке мені задали на співбесіді, і я не можу зрозуміти відповіді, яку вони шукали, тому сподіваюся, що хтось тут може мати якісь ідеї. Мета - написати функцію, яка гарантовано ніколи не поверне одне і те ж значення двічі. Припустимо, що до цієї функції будуть доступні декілька машин одночасно.

Моя ідея полягала в тому, щоб призначити кожній машині унікальний ідентифікатор і передати це значення в унікальну функцію генератора значень:

var i = 0;
function uniq(process_id, machine_id) {
   return (i += 1).toString() + machine_id + "-" + process_id;
}

Це дозволить уникнути випадання в умовах перегонів, оскільки навіть якщо два чи більше процесів читають одне і те ж значення i, кожне повернене значення позначається унікальною комбінацією ідентифікатора процесу та ідентифікатора машини. Однак моєму інтерв'юєру ця відповідь не сподобалася, оскільки приведення іншої машини в Інтернет означає присвоєння їй ідентифікатора.

Тож чи може хтось придумати інший спосіб вирішити це питання, який не передбачає налаштування кожної машини на унікальний ідентифікатор? Я хотів би отримати відповідь у випадку, якщо це запитання виникне знову. Спасибі.

Не майте фантазії, просто киньте простий лічильник (безпечний для потоків) за деякою кінцевою точкою зв’язку (WCF, веб-сервіс, що завгодно):

   long x = long.MinValue;
   public long ID(){
       return Interlocked.Increment(ref x);
   }

Так, вона з часом переповниться. Так, він не обробляє перезавантаження. Так, це не випадково. Так, хтось може це запустити на декількох серверах.

Це найпростіша річ, яка відповідає практичним вимогам. Тоді нехай вони будуть тими, хто вирішує ці проблеми (щоб переконатися, що вони розуміють обмеження, чи дійсно вони вважають, що вам потрібно більше 2 ^ 64 ід), тож ви можете запитати про те, які компроміси в порядку. Чи потрібно переживати перезавантаження? Що з відмовою на жорсткому диску? А як щодо ядерної війни? Чи потрібно це бути випадковим? Як випадково?

Якби мені було задано це питання, і вони дали зрозуміти, що воно повинно бути унікальним у перезавантаженнях і на різних машинах, я б дав їм функцію, яка запускає стандартний механізм для створення нового GUID, що б там не сталося мова, що використовується.

Інтерв'юер сказав, що метод буде називатися одночасно, а не паралельно; просто поверніть дату / час до стільки знаків після коми.

Чому всі переосмислюють це? Ви будете мертві довгий час, перш ніж буде витрачено будь-яку кінцевість, і у вас немає шансів зіткнення.

Якщо ви турбуєтесь про те, щоб повернутися в той же час, додайте затримку на найменшу кількість вимірюваного часу.

Якщо ви турбуєтесь про те, щоб повернути годинник на літній час (випробовуєте 1 раз двічі), додайте константу до часу, коли ви вдруге відчуєте це.

По-перше, вам потрібно буде задати інтерв'юєру два питання.

Питання 1.

чи інтерв'юер очікує, що одна або декілька "центральних машин" будуть використані для присвоєння деяких унікальних номерів або блоків унікальних номерів.

Питання 2.

Чи очікує інтерв'ю механізм виявлення зіткнень, чи замість цього прийме розрахований ризик мінусового шансу зіткнення без явного їх виявлення.

Існує також глибоко захищений підхід, в якому включена частина випадкових ідентифікаторів користувача у випадковість (таким чином, не зовсім випадкова). Таким чином, знижується ймовірність того, що той самий користувач зіткнеться із вмістом, створеним цим самим користувачем.

Існує неявне запитання 3, ...

Але це вам доведеться оцінити себе, не запитуючи, тому що запитувати свого інтерв'ю вкрай неввічливо.

Будь інтерв'юер припускає знання ймовірності, ризику та деяких простих прийомів, застосовуваних у криптографічних та інформаційно-захисних системах.

Перший вид знань гарантує, що ви не намагаєтесь переконати ненаукову людину у прийнятті наукової концепції, яку вони не приймуть.

Другий вид знань гарантує вирішення проблем, які є додатковою лише ймовірністю. Іншими словами, як захиститись від "нападників", які хочуть навмисно порушити вашу схему рандомізації, маніпулюючи машиною (машинами) або їх віртуальними хостами, щоб змусити дві машини генерувати однакове значення.

Навіщо питати.

Причина полягає в тому, що якщо інтерв'юер так чи інакше очікує, спроба відповісти протилежним підходом ніколи не зробить інтерв'юера щасливим.

Більш глибока причина полягає в тому, що деяким людям не подобається ідея сказати - 1.0e-20шанс провалитися. (Я постараюся тут не розпалювати філософські чи релігійні аргументи.)

Перш за все, "простір імен" випадкових чисел перетворюється на ієрархію, при цьому певна кількість бітів виділяється одному джерелу рандомізації, а інша кількість бітів, виділених якимись іншими способами тощо.

Централізований підхід покладається на деякий центральний орган, щоб однозначно призначити біт першого рівня. Потім інші машини можуть заповнити решту шматочків.

Існує кілька децентралізованих підходів:

• Просто генеруйте випадкові числа настільки добре, наскільки це могло, і прийміть практично нульовий шанс не виправданих обчислень.
• Використовуйте криптографічні засоби для генерування випадкових значень з детермінованого джерела, скажімо, збільшення значень.

Отже, маючи на увазі, що це питання інтерв'ю, а не фактичний сценарій реального життя, я вважаю, що правильним підходом (і, можливо, те, що шукає інтерв'юер) є задати уточнююче запитання або написати "Це не може робиться "і рухатися далі. Ось чому.

Що запитує інтерв'юер:

Напишіть функцію, яка гарантовано ніколи не поверне одне і те ж значення двічі. Припустимо, що до цієї функції будуть доступні кілька машин одночасно.

Що потрібно інтерв'юєру:

Чи ефективно оцінює цей кандидат вимоги та чи потребує додаткового внеску, коли це вимагається?

Ніколи не припускайте.

Коли інженеру вручається вимога (через SOW або Специфікацію або якийсь інший документ із вимогами), деякі є само собою зрозумілими, а інші - абсолютно незрозумілими. Це прекрасний приклад останнього. Як показали попередні відповіді, немає можливості відповісти на цю вимогу, не роблячи декількох основних припущень або (a) щодо природи питання або (b) щодо природи системи, оскільки вимога не може бути виконана як написано (неможливо).

Більшість відповідей робить ту чи іншу спробу вирішити проблему за допомогою ряду припущень. Спеціально рекомендується просто зробити це швидко і дозволити клієнту хвилюватися з цього приводу, якщо він неправильний.

Це дійсно поганий підхід. Як замовник, якщо я даю незрозумілу вимогу, а інженер відходить і розробляє мені рішення, яке не працює, я буду засмучуватися, що вони пішли на роботу і витратили мої гроші, не намагаючись спочатку запитати мене. Таке прийняття рішень кавалера свідчить про відсутність роботи в команді, невміння критично мислити та погану оцінку. Це може призвести до будь-яких негативних наслідків, включаючи втрату життя в критичній системі безпеки.

Чому задавати питання?

Справа, якщо ця вправа полягає в тому, що будувати дорого і забирати багато часу потрібно до неоднозначних вимог. У випадку з ОП вам поставили неможливе завдання. Вашою першою дією має стати запит на роз'яснення - що саме потрібно? Який ступінь унікальності потрібен? Що станеться, якщо значення не унікальне? Відповідь на ці запитання може бути різницею між кількома тижнями часу і кількома хвилинами. У реальному світі одним із найбільших рушійників витрат у складних системах (включаючи багато програмних систем) є нечіткі та недостатньо зрозумілі вимоги. Це призводить до дорогих і витратних за часом помилок, перепроектувань, розчарування клієнтів та команд, а також невмілого висвітлення засобів масової інформації, якщо проект досить великий.

Що відбувається, коли ти припускаєш?

З огляду на мій досвід роботи в аерокосмічній галузі та через дуже помітний характер аварійно-космічних збоїв, я люблю наводити приклади з цього домену, щоб проілюструвати важливі моменти. Розглянемо пару невдалих місій на Марсі - Марсовий кліматичний орбітер та Марський полярний десант. Обидві місії зазнали невдачі через проблеми із програмним забезпеченням - тому що інженери зробили неправдиві припущення, частково, через незрозумілі та погано передані вимоги.

Марсовий кліматичний орбіт - цей випадок, як правило, цитується як те, що відбувається, коли NASA намагається перетворити англійську мову на метричні одиниці. Однак це надмірно спрощена та погана репрезентація того, що насправді вийшло. Правда, виникла проблема перетворення, але це було пов’язано з погано переданими вимогами на етапі проектування та неправильною схемою перевірки / перевірки. Крім того, коли двоє різних інженерів помітили проблему, оскільки це було очевидно з даних про траєкторію польоту, вони не підняли проблему до належного рівня, оскільки вважали, що це помилка передачі. Якби команда операторів місії була б обізнана з цим питанням, був би достатній час для її виправлення та збереження місії. У цьому випадку виникла неможлива логічна умова, яка не була визнана тим, що це було, що призвело до дорогої відмови місії.

Марс Полярний десант- цей випадок трохи менш відомий, але, можливо, більш неприємний через його тимчасової близькості до провалу Марс Клімат Орбітер. У цій місії програмне забезпечення контролювало спускання ракети на землю Марсія. У точці на 40 метрів над поверхнею ноги земляного судна розгортаються, готуючись до посадки. На ногах також був датчик, який виявляв рух (сигналізував, коли вони вплинули), щоб повідомити програмному забезпеченню, щоб вимкнути двигун. Найкраща здогадка НАСА щодо того, що сталося (оскільки існує безліч можливих збоїв та неповних даних) полягає в тому, що випадкові коливання в ногах внаслідок їх розгортання одночасно і неправильно спрацьовують механізм відключення на 40 м над поверхнею, в результаті чого відбувається аварія та знищення 110 доларів США М космічний корабель. Ця можливість була піднята в процесі розвитку, але ніколи не звертався. Зрештою, команда програмного забезпечення зробила неправдиві припущення про те, як цей код потрібно запустити (одне з таких припущень полягає в тому, що помилковий сигнал був би занадто короткочасним, щоб його можна було сприймати, незважаючи на тести, що показували протилежне), і ці припущення ніколи не ставили під сумнів до після факт.

Додаткові міркування

Інтерв'ю та оцінка людей - справа хитра. Є кілька аспектів кандидата, які інтерв'юер, можливо, бажає дослідити, але одним із найважливіших є здатність ідивідуального до критичного мислення. З найрізноманітніших причин, не останньою з яких є те, що критичне мислення є погано визначеним, у нас дуже важко оцінювати навички критичного мислення.

Як інструктор з інженерії, один з моїх улюблених способів оцінювати здатність студента критично мислити - це поставити дещо неоднозначне запитання. Більш гострі студенти підхопили б несправне приміщення, відзначили це, і будь-яку відповідь, якщо врахувати передумову, або взагалі відмовитись від відповіді. Як правило, я б задавав питання, подібне до наступного:

Ви вибираєте креслення зі своєї роботи. Малюнок містить безліч різних описів, але найважливіші точки вказує на горизонтальну поверхню і говорить "Ідеально плоска". Поверхня довжиною 5 "шириною на 16", а частина виконана з алюмінію. Як ви будете обробляти деталь для створення цієї функції?

(До речі, ви були б вражені тим, як часто така погана специфікація з’являється на робочому місці.)

Я очікую, що студенти визнають, що створити ідеальну особливість неможливо, і що вони заявлять про це у своїй відповіді. Я, як правило, присуджую бонусний бал, якщо вони скажуть, що повернуться до дизайнера і попросять роз'яснення, перш ніж зробити участь. Якщо студент продовжує розповідати, як вони збираються досягти .001 планарності чи іншої складеної вартості, я присуджую нульові бали. Це допомагає мені зазначити моїм учням, що їм потрібно думати про більшу картину.

Нижня лінія

Якщо я опитую інженера (чи подібну професію), я шукаю когось, хто може критично мислити і ставити під сумнів те, що було поставлено перед ним. Я хочу, щоб хтось задав питання "Чи має це сенс?" .

Немає сенсу просити ідеально рівну частину, бо немає такої речі, як ідеальна. Немає сенсу просити функцію, яка ніколи не повертає повторюваного значення, оскільки така гарантія неможлива. У програмуванні ми часто чуємо фразу "сміття, сміття." Якщо вам передають сміття відповідно до вимог, ваша етична відповідальність зупиняється і задавати будь-яке питання допоможе вам виявити справжній намір. Якщо я беру інтерв'ю з кандидатом, і я даю їм незрозумілу вимогу, я очікую роз'яснень.

Гарантувати унікальність складно, оскільки комп'ютери не мають нескінченно великих змінних. Жодна реальна машина Тьюрінга не може.

Як я це бачу, тут є дві проблеми, і обидві мають налагоджені рішення.

• Паралельність. Кілька машин можуть потребувати значення одночасно. На щастя, сучасні процесори мають вбудовану паралельність, а деякі мови надають зручні для розробників засоби, щоб скористатися цим.
• Унікальність. Хоча неможливо гарантувати унікальність, ми можемо мати довільно великі змінні, які можуть містити значення настільки великі, що реальній системі було б дуже важко вичерпати всі унікальні значення

Ось моє рішення на Java:

public class Foo {
  private static BigInteger value = BigInteger.ZERO;
  private static final Lock lock = new ReentrantLock();

  public static BigInteger nextValue() {
    try {
      lock.lock();
      value = value.add(BigInteger.ONE);
      return value;
    }
    finally {
      lock.unlock();
    }
  }
}

BigInteger - це цілочисельний тип довільного розміру. Він може зростати, утримуючи величини, які є досить великими, навіть якщо не нескінченними. Блокування забезпечує одночасність, тому одне і те ж значення не може бути повернуто двічі двома одночасними запитами, що обслуговуються окремими потоками.

Я би відкрив функцію через порт на сервері; для виклику функції запитуючий апарат запитує з'єднання і йому надається одне, при цьому призначається ідентифікаційний код (послідовний номер для простоти). Кожного разу, коли повідомлення надсилається порту, що вимагає унікального значення, значення генерується шляхом об'єднання хеша MD5 поточної дати та часу з хешем MD5 ідентифікаційного коду.

Якщо вони хочуть більш пуленебезпечного рішення, вони повинні були б уточнити свої фактичні вимоги, а не бути розпливчастими щодо речей.

string uniq(string machine_id) 
{
   static long u = long.MinValue;
   Interlocked.Increment(ref u);

   //Time stamp with millisecond precison
   string timestamp = DateTime.UtcNow.ToString("yyyy-MM-dd HH:mm:ss.fff",
                                            CultureInfo.InvariantCulture);

   return machine_id + "-" + timestamp + "-" + u;
}

Описаним вище способом ми можемо переконатися, що значення повернення відрізняється, навіть якщо є перезапуск або навіть якщо вони викликаються одночасно з різних машин.