Chức năng được đảm bảo không bao giờ trả lại cùng một giá trị hai lần [đã đóng]


23

Đây là một câu hỏi tôi đã được hỏi trong một cuộc phỏng vấn xin việc và tôi không thể tìm ra câu trả lời mà họ đang tìm kiếm, vì vậy tôi hy vọng ai đó ở đây có thể có một số ý tưởng. Mục tiêu là viết một hàm được đảm bảo không bao giờ trả lại cùng một giá trị hai lần. Giả sử rằng chức năng này sẽ được truy cập đồng thời bởi nhiều máy.

Ý tưởng của tôi là gán cho mỗi máy một id duy nhất và chuyển giá trị đó vào hàm tạo giá trị duy nhất:

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

Điều này sẽ tránh được bụi phóng xạ từ các điều kiện cuộc đua vì ngay cả khi hai hoặc nhiều quá trình đọc cùng một giá trị i, mỗi giá trị trả về được gắn thẻ kết hợp duy nhất của id tiến trình và id máy. Tuy nhiên, người phỏng vấn của tôi không thích câu trả lời này vì đưa một máy khác lên mạng liên quan đến việc gán cho nó một id.

Vì vậy, bất cứ ai cũng có thể nghĩ ra một cách khác để giải quyết vấn đề này không liên quan đến việc cấu hình mỗi máy để có một id duy nhất? Tôi muốn có câu trả lời trong trường hợp câu hỏi này xuất hiện trở lại. Cảm ơn.


31
Đảm bảo theo nghĩa chặt chẽ của từ này? Ý tôi là, ngay cả Guids cũng sẽ bắt đầu lặp lại. Chúng tôi có thể không sống nữa, nhưng đảm bảo .. Và nhân tiện, ID quá trình không còn là duy nhất .
JensG

7
@CodesInChaos - Đó là một giả định khá khủng khiếp, vì nó là tầm thường trong một số hệ điều hành để thay đổi địa chỉ mac của bạn.
Telastyn

7
"Giả sử rằng chức năng này sẽ được truy cập đồng thời bởi nhiều máy" - thành thật mà nói, điều này có thể có nghĩa là "mã chạy trên mỗi máy một cách ngẫu nhiên, không có giao tiếp giữa các máy" hoặc "có một máy trung tâm / cơ sở dữ liệu trung tâm nơi có chức năng được cung cấp cho các máy khác, có sẵn qua mạng ". Bạn nên bắt đầu làm rõ điều này trước.
Doc Brown

28
Đó có phải là một câu hỏi mẹo? Ví dụ: một hàm chứa một vòng lặp vô hạn sẽ không bao giờ trả lại cùng một giá trị hai lần ..
Brendan

8
Có lẽ họ đang tìm kiếm một lập trình viên đặt câu hỏi về các yêu cầu không rõ ràng, thay vì đưa ra các giả định và chạy theo nó :)
theMayer 24/11/14

Câu trả lời:


60

Đừng ưa thích, chỉ cần ném một bộ đếm (chủ đề) đơn giản đằng sau một số điểm cuối giao tiếp (WCF, dịch vụ web, bất cứ điều gì):

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

Vâng, cuối cùng nó sẽ tràn. Có, nó không xử lý khởi động lại. Vâng, nó không phải là ngẫu nhiên. Vâng, ai đó có thể chạy này trên nhiều máy chủ.

Đây là điều đơn giản nhất đáp ứng yêu cầu thực tế. Sau đó, hãy để họ là người theo dõi những vấn đề đó (để đảm bảo họ hiểu được những hạn chế, họ có thực sự nghĩ rằng bạn cần nhiều hơn 2 ^ 64 id) không, vì vậy bạn có thể hỏi về việc đánh đổi là gì. Có cần phải sống sót khởi động lại? Lỗi ổ cứng thì sao? Chiến tranh hạt nhân thì sao? Có cần phải ngẫu nhiên? Làm thế nào ngẫu nhiên?


7
Đây là một câu trả lời tốt, bởi vì người phỏng vấn không bao giờ đặt câu hỏi để có được câu trả lời thẳng. Họ muốn bạn đưa ra câu trả lời nơi bạn có thể biện minh cho quyết định của mình. Nếu bạn hiểu tên miền, gần như bất kỳ câu trả lời nào sẽ phù hợp nếu bạn có thể biện minh cho nó.

7
Làm thế nào điều này được cho là hoạt động nếu mã chạy trên các máy khác nhau (vì vậy rõ ràng trong các quy trình khác nhau)? Mỗi quá trình sẽ có một bản sao khác nhau x. Và tôi nghĩ rằng không có lời giải thích về loại cơ chế lồng vào nhau trong đầu, câu trả lời này khá mơ hồ.
Doc Brown

7
@DocBrown "được truy cập bởi nhiều máy đồng thời" dường như ngụ ý rằng nhiều máy truy cập một chức năng trên một máy chủ. Nếu không thì nên viết "Nhiều máy sẽ chạy một bản sao của chức năng này cùng một lúc"
Falco

3
@LightnessRacesinOrbit: Tôi đoán đây có nghĩa là C # và System.Threading.Interlockedlớp, cung cấp gia số nguyên tử. Nhưng bạn cũng có thể đọc nó như một loại mã giả.
Doc Brown

3
Nếu tôi là người hỏi tôi sẽ rất không hài lòng với đề xuất này. Bắt đầu thực hiện một cái gì đó mà không cần biết những yêu cầu là một lá cờ đỏ lớn. Tôi mong bạn hỏi.
JensG

25

Nếu tôi được hỏi câu hỏi đó và họ đã nói rõ rằng nó phải là duy nhất trên các lần khởi động lại và trên các máy khác nhau, tôi sẽ cung cấp cho họ một chức năng gọi vào cơ chế tiêu chuẩn để tạo GUID mới, bất kể điều gì xảy ra ngôn ngữ đang được sử dụng.


Vấn đề với GUID v4 là chúng chỉ có khả năng là duy nhất, không được bảo đảm là duy nhất. Không phải là một vấn đề lớn trong thực tế, nhưng không thỏa mãn các yêu cầu nếu người phỏng vấn thực hiện chúng theo đúng nghĩa đen.
CodeInChaos

Cụ thể, nếu cơ chế GUID tiêu chuẩn không đáp ứng yêu cầu của người phỏng vấn, thì hãy trêu chọc sự khác biệt về yêu cầu giữa người phỏng vấn và người dùng GUID thông thường. Một người phỏng vấn hợp lý hỏi loại câu hỏi này ("làm thế nào để bạn làm <một số điều tiêu chuẩn thường được biết đến có lẽ với một chút thay đổi so với các yêu cầu thông thường>") nên mong đợi những câu trả lời rất khác nhau từ những ứng viên biết về tình trạng của nghệ thuật cho GUID và các ứng cử viên đang phát minh ra thứ gì đó từ đầu.
Steve Jessop

Đây có lẽ là câu trả lời đơn giản nhất, giả sử các yêu cầu linh hoạt.
Người chơi

9
+1 vì đây cơ bản là vấn đề mà các hướng dẫn giải quyết. Sản xuất một Guid trùng lặp, bất kể định dạng của nó, là loại xổ số khó nhất trên hành tinh. Rõ ràng nhiều người không có ý thức về sự không tương xứng theo cấp số nhân của các vụ va chạm.
usr

3
Ồ, và nếu bạn đưa ra câu trả lời "sử dụng chức năng tiêu chuẩn" cho bất kỳ câu hỏi nào như vậy, hãy chờ đợi câu hỏi tiếp theo "và chức năng tiêu chuẩn được triển khai như thế nào?". Bạn có thể trả lời rất rõ "Tôi không biết, nhưng tôi chắc chắn sẽ tìm kiếm nó hơn là cố gắng phát minh ra thứ gì đó", đó là một câu trả lời hoàn toàn chính xác, hoàn toàn không duy trì được sự nghi ngờ trong điều kiện phỏng vấn, mà bạn muốn bao giờ làm bất cứ điều gì quan trọng mà không nghiên cứu nó lần đầu tiên ;-)
Steve Jessop

22

Người phỏng vấn cho biết phương pháp này sẽ được gọi đồng thời, không song song; chỉ cần trả ngày / thời gian xuống càng nhiều số thập phân càng tốt.

Tại sao mọi người lại nghĩ quá nhiều về điều này? Bạn sẽ chết một thời gian dài trước khi bất kỳ sự hữu hạn nào được sử dụng và bạn không có cơ hội va chạm.

Nếu bạn lo lắng về việc nó sẽ quay lại cùng một lúc, hãy thêm độ trễ cho khoảng thời gian nhỏ nhất có thể đo được.

Nếu bạn lo lắng về việc đặt lại đồng hồ cho thời gian tiết kiệm ánh sáng ban ngày (trải qua 1 lần hai lần), hãy thêm hằng số vào lần thứ hai bạn trải nghiệm.


12
Hoặc chỉ trả lại thời gian UTC bất kể múi giờ của người yêu cầu. Vì UTC không được bản địa hóa nên nó sẽ không bị ảnh hưởng bởi các thay đổi DST.
Mauro

1
System.cienTimeNanos () :-)
Falco

1
Trừ khi bạn trả lại ngày & giờ ở định dạng có thể đọc được, giá trị của bạn không nên có bất kỳ thông tin múi giờ nào bên trong.
Cuộc đua nhẹ nhàng với Monica

12
Lượng thời gian nhỏ nhất vẫn sẽ tạo ra va chạm nếu được gọi là thường xuyên / đồng thời đủ. Nó cũng sẽ tạo ra va chạm do trôi đồng bộ hóa đồng hồ, thao tác đồng hồ độc hại và nếu bạn không cẩn thận - tiết kiệm ánh sáng ban ngày.
Telastyn

1
Rất sáng tạo, ít nhất. Dựa vào một chiếc đồng hồ sẽ được điều chỉnh mọi lúc và sau đó vẫn không phải là một ý tưởng tuyệt vời, IMHO. Việc bù đắp sẽ không cứu bạn khỏi va chạm.
JensG

15

Đầu tiên, bạn sẽ muốn hỏi người phỏng vấn hai câu hỏi.


Câu hỏi 1.

người phỏng vấn có mong muốn một hoặc nhiều "máy trung tâm" được sử dụng để gán một số số duy nhất hoặc khối số duy nhất hay không.


Câu hỏi 2.

Cho dù người phỏng vấn mong đợi một cơ chế phát hiện va chạm, hoặc thay vào đó chấp nhận rủi ro tính toán của cơ hội va chạm rất nhỏ mà không phát hiện rõ ràng.

Ngoài ra còn có cách tiếp cận chuyên sâu, trong đó người ta kết hợp một phần ID người dùng vào tính ngẫu nhiên (do đó, không hoàn toàn ngẫu nhiên). Do đó, khả năng cùng một người dùng gặp phải một xung đột trong nội dung được tạo bởi cùng một người dùng đó sẽ bị hạ thấp.


Có một câu hỏi ngầm 3, ...

Nhưng đó là một điều bạn sẽ phải tự đánh giá bản thân mà không cần hỏi, bởi vì việc hỏi người phỏng vấn bạn là vô cùng bất lịch sự.

Liệu người phỏng vấn có thừa nhận kiến ​​thức về xác suất, rủi ro và một số kỹ thuật đơn giản được sử dụng trong các hệ thống mật mã và bảo mật thông tin hay không.

Loại kiến ​​thức đầu tiên đảm bảo bạn không cố gắng thuyết phục một người không khoa học chấp nhận một khái niệm khoa học mà họ sẽ không chấp nhận.

Loại kiến ​​thức thứ hai đảm bảo rằng bạn giải quyết các mối quan tâm ngoài xác suất đơn thuần. Nói cách khác, làm thế nào để chống lại "kẻ tấn công", những kẻ muốn cố tình phá vỡ sơ đồ ngẫu nhiên của bạn, bằng cách thao tác (các) máy hoặc máy chủ ảo của chúng để buộc hai máy tạo ra cùng một giá trị.


Hỏi làm gì.

Lý do là nếu người phỏng vấn mong đợi nó bằng cách này hay cách khác, cố gắng trả lời theo cách tiếp cận ngược lại sẽ không bao giờ khiến người phỏng vấn hài lòng.

Lý do sâu xa hơn là một số người không thích ý tưởng nói, một 1.0e-20cơ hội thất bại. (Tôi sẽ cố gắng không khuấy động các tranh luận triết học hoặc tôn giáo ở đây.)


Trước hết, "không gian tên" của các số ngẫu nhiên được tạo thành một hệ thống phân cấp, với số bit nhất định được phân bổ cho một nguồn ngẫu nhiên và số bit khác được phân bổ cho một số cách khác, v.v.

Cách tiếp cận tập trung dựa vào một số cơ quan trung ương để chỉ định duy nhất mức bit đầu tiên. Sau đó, các máy khác có thể lấp đầy phần còn lại của các bit.

Có một số cách tiếp cận phi tập trung:

  • Chỉ cần tạo ra các số ngẫu nhiên tốt nhất có thể, và chấp nhận cơ hội thất bại thực tế bằng không bằng cách tính toán.
  • Sử dụng các phương tiện mã hóa để tạo ra các giá trị ngẫu nhiên từ nguồn xác định, giả sử, một giá trị tăng dần.

Tôi nghĩ rằng đây là câu trả lời tốt nhất. Những người khác là giải pháp mà không có yêu cầu.
Jack Aidley

Nhận xét về câu hỏi thứ ba của bạn - có vẻ như năng lực là một giả định an toàn, hoặc ít nhất là một câu hỏi không liên quan. Nếu một công ty không cung cấp một người phỏng vấn có thẩm quyền, có khả năng sẽ có những sai sót lớn hơn trong quá trình lựa chọn. Nếu họ đã làm, sau đó anh ấy / cô ấy sẽ đánh giá cao các câu hỏi.
Người chơi

1
Tại sao "câu hỏi 3" không thể được giải quyết bằng cách hỏi điều gì đó, "Chúng ta có cần sự duy nhất thực sự được đảm bảo hay chỉ là một xác suất va chạm rất, rất thấp?" và, "Điều này cần an toàn đến mức nào? Chúng ta có cần cho rằng kẻ tấn công sẽ cố phá vỡ cơ chế không? Chúng ta quan tâm đến loại tấn công nào?" Câu trả lời cho những câu hỏi đó nên làm rõ liệu người hỏi có hiểu những vấn đề này và những gì họ mong đợi hay không.
jpmc26

12

Vì vậy, hãy nhớ rằng đây là một câu hỏi phỏng vấn chứ không phải là một kịch bản thực tế thực tế, tôi tin rằng cách tiếp cận chính xác (và có lẽ những gì người phỏng vấn đang tìm kiếm) là hỏi một câu hỏi rõ ràng hoặc viết "Không thể được thực hiện "và tiếp tục. Đây là lý do tại sao.

Những gì người phỏng vấn hỏi:

Viết hàm được đảm bảo không bao giờ trả lại cùng một giá trị hai lần. Giả sử rằng chức năng này sẽ được truy cập đồng thời bởi nhiều máy.

Người phỏng vấn cần gì:

Ứng viên này có đánh giá hiệu quả các yêu cầu và tìm kiếm đầu vào bổ sung khi được yêu cầu không?

Không bao giờ giả định.

Khi một kỹ sư được trao một yêu cầu (thông qua SOW hoặc Thông số kỹ thuật hoặc một số tài liệu yêu cầu khác), một số là hiển nhiên và một số khác hoàn toàn không rõ ràng. Đây là một ví dụ hoàn hảo về sau này. Như các câu trả lời trước đã chỉ ra, không có cách nào để đáp ứng yêu cầu này mà không đưa ra một số giả định chính về bản chất của câu hỏi hoặc (b) về bản chất của hệ thống, bởi vì yêu cầu không thể được đáp ứng như đã viết (nó là không thể).

Hầu hết các câu trả lời thực hiện một nỗ lực này hoặc nỗ lực khác để giải quyết vấn đề thông qua một loạt các giả định. Một người đặc biệt khuyên bạn chỉ nên hoàn thành nhanh chóng và để khách hàng lo lắng về điều đó nếu nó sai.

Đây thực sự là một cách tiếp cận tồi. Là một khách hàng, nếu tôi đưa ra một yêu cầu không rõ ràng, và kỹ sư bỏ đi và xây dựng cho tôi một giải pháp không hiệu quả, tôi sẽ buồn vì họ đã đi làm và tiêu tiền của tôi mà không cần hỏi tôi trước. Đó là kiểu ra quyết định ung dung thể hiện sự thiếu tinh thần đồng đội, không có khả năng suy nghĩ phê phán và phán đoán kém. Nó có thể dẫn đến bất kỳ cách nào gây ra hậu quả tiêu cực, bao gồm mất mạng trong một hệ thống quan trọng về an toàn.

Tại sao đặt câu hỏi?

Điểm nếu bài tập này là tốn kém và mất thời gian để xây dựng theo yêu cầu mơ hồ. Trong trường hợp của OP, bạn đã được giao một nhiệm vụ bất khả thi. Hành động đầu tiên của bạn là yêu cầu làm rõ - điều gì là bắt buộc? Mức độ duy nhất là cần thiết? Điều gì xảy ra nếu một giá trị không phải là duy nhất? Câu trả lời cho những câu hỏi này có thể là sự khác biệt giữa vài tuần thời gian và vài phút. Trong thế giới thực, một trong những yếu tố chi phí lớn nhất trong các hệ thống phức tạp (bao gồm nhiều hệ thống phần mềm) là không rõ ràng và các yêu cầu kém hiểu biết. Điều này dẫn đến các lỗi tốn kém và tốn thời gian, thiết kế lại, sự thất vọng của khách hàng và nhóm và phủ sóng truyền thông nếu dự án đủ lớn.

Điều gì xảy ra khi bạn giả định?

Với nền tảng của tôi trong ngành hàng không vũ trụ, và do tính chất dễ thấy của các sự cố hàng không vũ trụ, tôi muốn đưa ra các ví dụ từ lĩnh vực này để minh họa các điểm quan trọng. Chúng ta hãy kiểm tra một cặp nhiệm vụ trên sao Hỏa thất bại - Tàu quỹ đạo Khí hậu Sao Hỏa và Tàu địa cực Mars. Cả hai nhiệm vụ đều thất bại do sự cố phần mềm - bởi vì các kỹ sư đưa ra các giả định không hợp lệ, một phần, do các yêu cầu không rõ ràng và giao tiếp kém.

Mars Climate Orbiter - trường hợp này thường được trích dẫn là những gì xảy ra khi NASA cố gắng chuyển đổi tiếng Anh sang đơn vị Số liệu. Tuy nhiên, đó là một đại diện quá đơn giản và nghèo nàn về những gì thực sự xảy ra. Đúng, đã có một vấn đề chuyển đổi, nhưng đó là do các yêu cầu giao tiếp kém trong giai đoạn thiết kế và sơ đồ xác minh / xác nhận không phù hợp. Hơn nữa, khi hai kỹ sư khác nhau nhận thấy vấn đề vì rõ ràng từ dữ liệu quỹ đạo bay, họ đã không nâng vấn đề lên mức phù hợp vì họ cho rằng đó là lỗi truyền. Đội ops nhiệm vụ đã được nhận thức về vấn đề này, có đủ thời gian để sửa nó và cứu nhiệm vụ. Trong trường hợp này, có một điều kiện logic không thể không được công nhận cho những gì nó đã dẫn đến thất bại nhiệm vụ tốn kém.

Tàu đổ bộ sao hỏa- trường hợp này ít được biết đến hơn, nhưng có thể còn lúng túng hơn do sự gần gũi tạm thời của nó với sự thất bại của Tàu quỹ đạo Sao Hỏa. Trong nhiệm vụ này, phần mềm đã điều khiển dòng dõi được hỗ trợ của tên lửa đẩy vào bề mặt sao Hỏa. Tại một điểm cách mặt đất 40 mét, chân của tàu đổ bộ được triển khai để chuẩn bị hạ cánh. Ngoài ra còn có một cảm biến trên chân phát hiện chuyển động (để báo hiệu khi chúng bị va chạm) để báo cho phần mềm tắt động cơ. Dự đoán tốt nhất của NASA về những gì đã xảy ra (vì có nhiều lỗi hỏng hóc và dữ liệu không đầy đủ) là các rung động ngẫu nhiên ở chân do triển khai đồng thời và kích hoạt không đúng cách cơ chế tắt máy 40m trên bề mặt, dẫn đến sự cố và phá hủy $ 110 Tàu vũ trụ M. Khả năng này đã được đưa ra trong sự phát triển, nhưng không bao giờ được giải quyết. Cuối cùng, nhóm phần mềm đã đưa ra các giả định không hợp lệ về cách mã này cần chạy (một giả định như vậy là tín hiệu giả sẽ quá ngắn để được chọn, mặc dù các thử nghiệm cho thấy điều ngược lại), và các giả định đó không bao giờ bị nghi ngờ cho đến sau sự thật.

Xem xét bổ sung

Phỏng vấn và đánh giá con người là một công việc khó khăn. Có một số khía cạnh của một ứng cử viên mà một người phỏng vấn có thể muốn khám phá, nhưng một trong những điều quan trọng nhất là khả năng suy nghĩ nghiêm túc của một cá nhân. Vì nhiều lý do, không phải ít nhất trong số đó là tư duy phê phán được định nghĩa kém, chúng ta có một thời gian rất khó để đánh giá các kỹ năng tư duy phê phán.

Là một giảng viên kỹ thuật, một trong những cách yêu thích của tôi để đánh giá khả năng suy nghĩ nghiêm túc của học sinh là hỏi một câu hỏi hơi mơ hồ. Các sinh viên sắc nét hơn sẽ chọn ra tiền đề sai lầm của câu hỏi, lưu ý nó và hoặc trả lời được đưa ra tiền đề hoặc từ chối trả lời hoàn toàn. Thông thường, tôi sẽ hỏi một câu hỏi tương tự như sau:

Bạn chọn một bản vẽ từ đống công việc của bạn. Bản vẽ chứa nhiều loại chú thích khác nhau, nhưng những điểm quan trọng nhất đối với bề mặt nằm ngang và nói "Hoàn toàn phẳng". Bề mặt rộng 5 "dài 16" và phần được làm bằng nhôm. Làm thế nào bạn sẽ máy phần để tạo ra tính năng này?

(Nhân tiện, bạn sẽ bị sốc khi tần suất xuất hiện một thông số kém như vậy ở nơi làm việc.)

Tôi hy vọng rằng các sinh viên sẽ nhận ra rằng không thể tạo ra một tính năng hoàn hảo và họ sẽ nêu điều này trong câu trả lời của họ. Tôi thường sẽ thưởng một điểm thưởng nếu họ nói rằng họ sẽ quay lại nhà thiết kế và yêu cầu làm rõ trước khi thực hiện phần này. Nếu một học sinh tiến hành cho tôi biết làm thế nào họ sẽ đạt được 0,001 độ phẳng hoặc một số giá trị tạo thành khác, tôi sẽ không có điểm nào. Điều này giúp tôi đưa ra quan điểm với các sinh viên của mình rằng họ cần phải nghĩ về bức tranh lớn hơn.

Dòng dưới cùng

Nếu tôi đang phỏng vấn một kỹ sư (hoặc nghề nghiệp tương tự), tôi đang tìm kiếm một người có thể suy nghĩ chín chắn và đặt câu hỏi về những gì đã được đặt trước mặt anh ta. Tôi muốn ai đó đặt câu hỏi "Điều này có ý nghĩa không?" .

Không có nghĩa gì khi yêu cầu một phần hoàn toàn bằng phẳng, bởi vì không có thứ gì là hoàn hảo. Không có nghĩa gì khi yêu cầu một hàm không bao giờ trả về giá trị trùng lặp, vì không thể đảm bảo như vậy. Trong lập trình, chúng ta thường nghe thấy cụm từ "rác vào, rác ra". Nếu bạn được giao rác cho các yêu cầu, trách nhiệm đạo đức của bạn là dừng lại và hỏi bất kỳ câu hỏi nào giúp bạn khơi gợi ý định thực sự. Nếu tôi đang phỏng vấn một ứng cử viên, và tôi đưa ra cho họ một yêu cầu không rõ ràng, tôi sẽ mong đợi những câu hỏi làm rõ.


5

Đảm bảo tính duy nhất là khó khăn vì máy tính không có các biến số vô cùng lớn. Không có máy Turing trong thế giới thực có thể.

Theo tôi thấy có hai vấn đề ở đây và cả hai đều có giải pháp được thiết lập tốt.

  • Đồng thời. Nhiều máy có thể cần một giá trị cùng một lúc. Rất may, các CPU hiện đại có tích hợp đồng thời và một số ngôn ngữ cung cấp các tiện ích thân thiện với nhà phát triển để tận dụng lợi thế này.
  • Độc đáo. Mặc dù không thể đảm bảo tính duy nhất, chúng ta có thể có các biến lớn tùy ý có thể chứa các giá trị lớn đến mức một hệ thống trong thế giới thực sẽ có một thời gian rất khó khăn để làm cạn kiệt tất cả các giá trị duy nhất

Đây là giải pháp của tôi trong 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 là một kiểu số nguyên kích thước tùy ý. Nó có thể phát triển để giữ các giá trị khá lớn, ngay cả khi không phải là vô hạn. Khóa đảm bảo đồng thời, do đó, cùng một giá trị không thể được trả về hai lần bởi hai yêu cầu đồng thời được phục vụ bởi các luồng riêng biệt.


Tôi nghĩ rằng giả định rằng mã sẽ chỉ được sử dụng dưới năm trăm năm là một giả định hợp lệ. Nếu bạn chỉ đơn giản trả về các giá trị tăng trong bộ nhớ 64 bit, bạn sẽ ổn trong một thời gian. Tại 1 cuộc gọi mỗi chúng tôi, trong 584555 năm.
Vịt Mooing

1
Ít nhất là trong Java, đó là 2 ^ 63 giá trị (quá một nửa). Vẫn còn lâu hơn loài người có thể sẽ tồn tại do xu hướng giết nhau của chúng ta. Bất kể, tôi đã có một cách tiếp cận lý thuyết hơn. Trên thực tế, 64 (hoặc 63) bit là đủ.

1
@Snowman: CÁI GÌ?!? Giải pháp của bạn chỉ có giá trị trong 250K năm?!?!? TIẾP THEO TIẾP THEO !!!!!! :-)
Bob Jarvis - Phục hồi Monica

0

Tôi sẽ hiển thị chức năng thông qua một cổng trên máy chủ; để gọi hàm, máy yêu cầu yêu cầu kết nối và được cấp một kết nối, đồng thời được cấp một mã nhận dạng (số thứ tự để đơn giản). Bất cứ khi nào một tin nhắn được gửi đến cổng yêu cầu giá trị duy nhất, giá trị đó được tạo bằng cách ghép băm MD5 của ngày và giờ hiện tại với băm MD5 của mã nhận dạng.

Nếu họ muốn một giải pháp chống đạn nhiều hơn, họ sẽ phải xác định các yêu cầu thực tế của họ thay vì mơ hồ về mọi thứ.


-1
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;
}

Theo cách trên, chúng tôi có thể đảm bảo rằng giá trị trả về là khác nhau ngay cả khi có khởi động lại hoặc ngay cả khi được gọi đồng thời từ các máy khác nhau.


Lập trình viên là về câu hỏi khái niệm và câu trả lời dự kiến ​​sẽ giải thích mọi thứ. Ném các đoạn mã thay vì giải thích giống như sao chép mã từ IDE sang bảng trắng: nó có thể trông quen thuộc và thậm chí đôi khi có thể hiểu được, nhưng nó cảm thấy kỳ lạ ... chỉ là lạ. Bảng trắng không có trình biên dịch
gnat

Cảm ơn gnat đã chỉ ra nó, sẽ cẩn thận giải thích giải pháp từ lần sau
techExplorer
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.